JIT-Bitmap-Textrendering: Raph Levien bringt proportionale Schriften auf den RP2350
JIT bitmap text rendering for microcontrollers
Raph Levien stellt eine JIT-Technik vor, die Bitmap-Text auf dem RP2350-Mikrocontroller extrem schnell rendert. Statt eines Framebuffers füllt der Renderer den Videospeicher zeilenweise („race the beam“) und erzeugt zur Laufzeit optimierten ARM-Assembler-Code für jeden String. Die Schrift ist so dicht gepackt, dass sie von 1140 auf 960 Bytes schrumpft; der zweite Durchlauf erreicht 1,75 Zyklen pro Pixel. Das ermöglicht proportionale Schriften mit Kerning und niedrige Latenz.
Die Schrift muss im SRAM liegen, denn im Flash könnte sie während des Renderings mit Videogeschwindigkeit Stockungen verursachen.
- drfuchs
Für frühere verwandte Arbeiten schau dir das Patent US-6377261-B1 „Compiling glyphs into instructions for imaging for execution on a general purpose computer“ an, eingereicht 1996. Die Grundidee ist, dass jedes Zeichen in eine Folge von „Load Immediate“-/„Shift“-/„OR to Memory“-Instruktionen umgewandelt wird; es gibt also kein Abrufen mehr aus einem gespeicherten Bitmap der Schrift, da die Pixel implizit in den Immediate-Daten des generierten Maschinencodes enthalten sind. Dann kann man es aufwendiger gestalten, wenn eine Pixelzeile mit der vorherigen Zeile im Zeichen identisch ist, sodass man nicht einmal das Load Immediate benötigt. Usw. Dieses Schema wurde damals in FrameMaker für Macintosh verwendet, implementiert von Gus Fernandez (der bei zusätzlichen Optimierungen völlig überdrehte).
- karmakaze
Das ist ein wirklich großartiges Projekt. So viele Retro-Computer sind OP, dass sie große Framebuffer nutzen können, und das Programmieren dafür fühlt sich nicht mehr so an wie früher, als man näher an der Hardware war, was irgendwie intimer war.
Diese Implementierung erinnert mich an zwei meiner frühen Erfahrungen: das Programmieren von Display Lists auf Atari 8-Bit und einen HP PCL 5e Interpreter (mit kurzem Rasterband-Puffer). Mit VCS/2600 128-Byte Beam Racing bin ich nicht wirklich warm geworden, aber ich habe einiges an Display-List-Interrupt-On-the-Fly-Coding für selbstgemachte Spiele und Demos gemacht. Ich fand das Atari Antic Display-List-System großartig – danke an Jay Miner, der auch den Amiga gemacht hat – und habe bis OS/2 Presentation Manager oder Java FX nicht viel Ähnliches gesehen.
Der PCL-Interpreter hatte wohl die ähnlichste Form mit einem zyklischen Puffer von ein paar hundert Zeilen. Er „renderte“ in y-sortierte Objekte, die später gerendert/rasterisiert werden mussten. Jedes Objekt wurde so zugeschnitten, dass es höchstens 255 Pixel (0,85 Zoll) hoch war, und verwendete eine umgekehrte Max-Y-Reihenfolge, da es nicht gezeichnet werden konnte, bevor der Strahl die Umbruch-Scanline passiert hatte, die noch Y - Pufferhöhe renderte.
- codazoda
Ich habe an BASIC32 gearbeitet, einem Retro-BASIC-Interpreter für Mikrocontroller, damit ich ihn einmal flashen und einfach viele neue Projekte erstellen kann.
Was man bei dem Ansatz des Autors aufgibt, ist „read“. Der Bildschirm wird nur noch beschreibbar. Es gibt nur wenige Funktionen, die Reads erfordern: das Abrufen der aktuellen Farbe eines Pixels und Operationen wie Flood Fills oder Paints.
Da ich das Retro-Gefühl von BASIC anstrebte, wollte ich diese unterstützen, also entschied ich mich für einen Framebuffer. Das ist technisch nicht so cool. Auf dem RP2350 erfordert es niedrige Auflösung und niedrige Bitraten, weil der RAM oft auf KB begrenzt ist.
Wenn man zu den ESP32-S3-Varianten mit 4 MB oder 8 MB RAM aufsteigt, wird der Framebuffer viel einfacher.