Was das Panel wirklich zeichnet

LEVEL
7. September 2026
PAP-021

Eine Oberfläche auf diesem Board hat eine harte Grenze, und sie liegt nicht dort, wo man sie vermutet. Gemessen auf dem Gerät: ein Ausschnitt kostet fast nichts und läuft mit der vollen Bildrate des Panels, eine ganze Fläche kostet fast eine Zehntelsekunde, und Bilder kosten davon noch einmal das Doppelte. Zwei Bibliotheken sind denselben Ablauf gelaufen, Slint und LVGL, und bei Flächen und Text nehmen sie sich nichts. Bei Bildern liegen sie um das Zweieinhalbfache auseinander, und daran hängt die Mediathek.

1. Was gemessen wurde und warum

Der Entwurf des Bedienteils steht als Zeichnung fest, aber niemand wusste, ob er sich auf diesem Board bewegen lässt. Die einzige Zahl, die es dazu gab, war die Zeit für ein Vollbild aus dem Board-Datenblatt, 53 Millisekunden, und daraus abgeleitet eine Obergrenze von neunzehn Bildern je Sekunde. Das sagt aber nichts darüber, was eine Oberfläche tatsächlich tut, denn die zeichnet fast nie ein Vollbild.

Gemessen wurde deshalb an einer laufenden Oberfläche auf dem Gerät, und zwar an den vier Bewegungen, die ein Bedienteil braucht: ein Slider unter dem Finger, eine rollende Liste, einen Dialog, die erscheint, und ein Bildschirm, der zur Seite wandert. Dazu kam ein Gitter aus Coverkacheln, weil die Mediathek eines zeigt.

Dieselbe Oberfläche entstand zweimal, einmal mit Slint und einmal mit LVGL. Beide Male lief derselbe feste Ablauf ohne Finger, mit denselben Sprüngen und denselben Wartezeiten, damit sich die Läufe überhaupt vergleichen lassen. Was ein Mensch dabei tut, ist keine Messgrundlage, weil er beim zweiten Mal anders wischt als beim ersten.

Gezählt wurde nicht, was gerechnet wurde, sondern was auf das Panel ging. Der Aufruf, mit dem Bildpunkte an die Anzeige gehen, ist umschlossen und zählt Aufrufe und Bildpunkte mit. Ein Bild ist damit ein Bild. Derselbe Zähler saß in beiden Fassungen an derselben Stelle.

2. Die drei Zahlen

Die erste Zeile ist die gute Nachricht. Ein Slider, den ein Finger zieht, ändert rund vierhundertfünfzig Bildpunkte je Bild und läuft damit mit 36 Bildern je Sekunde, während das Panel selbst 39 schafft. Er ist am Anschlag der Hardware, und er fühlt sich auch so an.

Die zweite ist die Grenze. Der Renderer schafft rund 4,3 Millionen Bildpunkte je Sekunde. Ein Vollbild sind 384.000, also bleiben elf bis dreizehn Vollbilder je Sekunde übrig. Alles, was die ganze Fläche in Bewegung setzt, landet dort, und dreizehn Bilder je Sekunde sieht man als Ruckeln.

Die dritte sagt, was Bilder kosten. Dasselbe Rollen mit Coverkacheln statt mit Flächen und Text fällt auf 2,0 Millionen Bildpunkte je Sekunde, also auf gut fünf Vollbilder. Ein Bildpunkt aus einem Bild kostet etwa doppelt so viel wie einer aus einer Fläche.

Die Beleuchtung lässt sich dimmen, aber nicht mit jeder Frequenz. Bei zehn Kilohertz geht die Lampe beim ersten Schritt unterhalb des Anschlags aus, statt schwächer zu werden: der Treiber hinter dem Pin kommt gar nicht erst hoch. Bei 1220 Hz folgt sie dem Tastverhältnis über den ganzen Weg, geprüft von 34 bis 100 Prozent in 185 Schritten mit einem Regler auf dem Glas.

Die Zahl ist die, die eine erprobte Konfiguration für dieses Panel verwendet, und sie sieht willkürlich aus. Wer sie auf einen runden Wert bringt, schaltet die Beleuchtung ab.

3. Was daraus für den Entwurf folgt

Eine rollende Liste ist der teuerste Dauerzustand überhaupt, weil sich bei jedem Bild jeder Bildpunkt ändert, und sie landet damit bei elf bis dreizehn Bildern je Sekunde. Das ist der Preis, und er ist zu bezahlen: eine Liste rollt, weil das ist, was ein Mensch von einer Liste erwartet. Was die Messung dazu beiträgt, ist die Zahl und nicht die Entscheidung.

Was die ganze Fläche betrifft, wechselt sofort. Keine Blende, kein Überblenden, kein Einfahren. Eine Dialog erscheint. Ein Seitenwechsel kostet nach diesen Zahlen grob hundert bis hundertfünfzig Millisekunden, und das liest sich als Umblättern, solange nichts dabei animiert wird. Animiert man es, wird aus einem Umblättern ein Ruckeln über eine Viertelsekunde.

Animiert wird, was einen Ausschnitt betrifft. Ein Button, der seine Farbe wechselt, ein Griff, der einer Berührung folgt, ein Balken, der wächst, ein Icon, das erscheint. Das läuft am Anschlag und darf sich Zeit nehmen.

Eine vierte Regel kam nicht aus einer Zahl, sondern aus dem Hinsehen, und sie gilt trotzdem. Was sich bei einem Zustandswechsel gemeinsam ändert, muss sich gemeinsam bewegen. Bei einer Reihe von Buttons war die Füllfarbe animiert und die Kante nicht, und die Auswahl wechselte beim Loslassen statt beim Aufsetzen. Beides zusammen ließ einen Vorgang wie zwei aussehen: erst wurde der angetippte Button hell, dann ging der andere aus. Geometrisch war daran nichts falsch, und keine Prüfung hätte es gefunden.

4. Die zweite Bibliothek am selben Ablauf

Die Zahlen oben sagen, was dieses Board leistet, solange man Slint dafür nimmt. Ob sie am Board hängen oder am Werkzeug, entscheidet nur ein zweiter Lauf mit einem anderen Werkzeug. Also entstand dieselbe Oberfläche noch einmal mit LVGL, mit denselben fünf Seiten, demselben Ablauf und demselben Zähler.

Bei Flächen und Text sind beide gleich schnell. Der Unterschied von 12,5 zu 12,1 Bildern je Sekunde liegt im Rauschen zweier Läufe, und damit ist die Grenze aus Abschnitt 2 bestätigt: rund vier Millionen Bildpunkte je Sekunde sind das, was dieser Chip rechnet, und keine Eigenschaft der einen Bibliothek. Alle drei Entwurfsregeln gelten also unabhängig davon, womit gebaut wird.

Bei Bildern gehen sie auseinander, und zwar deutlich. Dasselbe Gitter läuft mit LVGL zweieinhalb Mal so schnell. Der Abstand ist noch bemerkenswerter, als er aussieht, denn die beiden hatten unterschiedlich viel zu tun: Slint hatte seine Bilder beim Bauen fertig aufbereitet im Flash liegen, LVGL entpackt bei jedem Fehlgriff im Zwischenspeicher eine PNG zur Laufzeit. Der Weg mit der Mehrarbeit ist der schnellere.

Die kleinere Binärdatei geht in dieselbe Richtung, aus demselben Grund. LVGL bringt den Decoder mit und braucht die Bilder deshalb nicht im Flash; Slints Fassung wuchs allein durch vier Kacheln um 346 KB.

Ein Befund gehört nicht in diese Tabelle, weil er sich nicht zählen lässt. Beide Fassungen wurden von Hand bedient, und die mit LVGL fühlt sich erheblich besser an. Die Bildrate erklärt das nicht, denn sie ist dieselbe. Die Erklärung liegt vermutlich woanders: LVGL bringt für Wischen und Rollen ein eigenes Verhalten mit, mit Trägheit und Nachlauf, während dasselbe bei Slint für diesen Versuch von Hand nachgebaut wurde. Das ist ein Unterschied im Bedienmodell und nicht in der Rechenleistung, und er ist damit auch kein Beleg gegen Slint.

5. Die Cover der Mediathek

Der größte Befund dieser Messung ist keine Bildrate. Die vier Coverkacheln des Versuchs kosten 346 KB Flash und rund 20 KB Arbeitsspeicher, also 86 KB je Kachel von 152 Punkten. Sie sind beim Bauen eingebettet und liegen schon in der Form vor, die der Renderer braucht; zur Laufzeit wird nichts entpackt. Deshalb ist das Gitter überhaupt so schnell, wie es ist.

Für die Mediathek geht dieser Weg nicht. Ihre Cover liegen auf der Speicherkarte, sind zur Bauzeit unbekannt, und es können hunderte sein. Bei 86 KB je Stück wäre schon ein Bruchteil der Sammlung größer als der gesamte Flash von 16 MB. Sie müssen also zur Laufzeit gelesen, entpackt, auf Kachelgröße gebracht und behalten werden.

Genau das ist der Grund, warum der Vergleich aus Abschnitt 4 überhaupt geführt wurde, und er hat die Frage beantwortet. Slints Übersetzung für diesen Chip bringt keinen Decoder für PNG oder JPEG mit, weil sie Bilder beim Bauen einbettet. LVGL bringt einen mit, und das Gitter im Versuch entpackt die Kacheln damit zur Laufzeit, während es schneller läuft als das eingebettete.

Der Zwischenspeicher ist dabei nicht der Feinschliff, sondern der Kern, denn ein Durchgang durch achtunddreißig Alben würde sonst achtunddreißig Mal von vorn anfangen. Im Versuch stand er auf zwei Megabyte, was bei rund 92 KB je entpacktem Cover etwa zwanzig Kacheln entspricht. Mit dem Vorgabewert von null lief gar nichts: der Decoder hatte keinen Ort für sein Ergebnis, und das Gitter blieb leer, ohne dass eine Meldung darauf hinwies.

Was für die Mediathek offen bleibt, ist der Weg von der Karte bis zum Decoder, also Lesen, Skalieren auf Kachelgröße und eine Strategie dafür, was der Zwischenspeicher verwirft, wenn er voll ist. Das Entpacken selbst ist keine Frage mehr.

6. Das weisse Aufblitzen beim Einschalten

Beim Einschalten zeigte das Panel für einen Moment ein volles Weiss, bevor das Bild kam. Das ist kein Fehler des Panels, sondern eine Frage der Reihenfolge, und die Ursache liegt an einer Stelle, an der man sie nicht sucht.

Ein RGB-Panel hat keinen eigenen Speicher. Es zeigt, was der Controller ihm in dem Moment schickt, und der schickt den Inhalt seines Bildpuffers. Solange dort nichts Gezeichnetes steht, steht dort das, was der Speicher beim Einschalten enthielt. Wird in diesem Zustand die Beleuchtung eingeschaltet, ist genau das zu sehen.

Die Reparatur ist eine Zeile Reihenfolge: gemessen erst zeichnen, dann beleuchten. Der Startbildschirm wird gebaut, einmal ausgegeben, und erst danach fährt die Beleuchtung hoch. Damit ist das Aufblitzen weg.

Zwei weitere Änderungen gehören dazu, weil sie unabhängig von der Reihenfolge richtig sind und weil sie ohne sie wirkungslos bleiben.

Die Bildpuffer werden geleert, bevor das Panel sie zum ersten Mal ausliest. Der Treiber legt sie im PSRAM an und sagt nichts über ihren Inhalt. Das Leeren allein genügt nicht: der Prozessor schreibt durch den Cache, das Panel liest den Speicher per direktem Zugriff daran vorbei. Ohne ein Zurückschreiben des Caches ist der Puffer für den Prozessor schwarz und für das Panel unverändert.

Und die Beleuchtungsleitung wird im Bootloader tief gezogen, so früh wie mit Code erreichbar. Das ist eine Vorsichtsmassnahme, keine Reparatur: gemessen liegt GPIO 2 auf dieser Platine schon 63 Millisekunden nach dem Zurücksetzen tief, und eine Fassung, die die Beleuchtung nie einschaltet, blitzt nicht. Die Platine wirft die Lampe also nicht von selbst an.

Die Beleuchtung lässt sich dimmen, aber nicht mit jeder Frequenz. Bei zehn Kilohertz geht die Lampe beim ersten Schritt unterhalb des Anschlags aus, statt schwächer zu werden: der Treiber hinter dem Pin kommt gar nicht erst hoch. Bei 1220 Hz folgt sie dem Tastverhältnis über den ganzen Weg, geprüft von 34 bis 100 Prozent in 185 Schritten mit einem Regler auf dem Glas.

Die Zahl ist die, die eine erprobte Konfiguration für dieses Panel verwendet, und sie sieht willkürlich aus. Wer sie auf einen runden Wert bringt, schaltet die Beleuchtung ab.

7. Was sich seither geändert hat

Die Zahlen oben gelten für die Fassung, in der sie gemessen wurden. Am 8. September 2026 hat sich der Weg zum Panel geändert, und eine heute genommene Zahl ist mit ihnen deshalb nur eingeschränkt vergleichbar.

Der DMA wird nicht mehr auf den Bildpuffer im PSRAM gerichtet, sondern über einen kleinen Zwischenpuffer im internen Speicher gespeist, zehn Zeilen auf einmal. Der Grund war ein Fehler und keine Feinabstimmung: nach ein paar schnellen Berührungen stand das Bild dauerhaft seitlich versetzt, und was rechts hinausfiel, erschien links. Espressif beschreibt das für diesen Baustein. Fällt der DMA hinter dem Panel zurück, weil die Nachfrage nach dem PSRAM kurz zu hoch ist, schiebt das Panel Fülldaten hinaus, und danach stimmen die Adresse, aus der gelesen wird, und die, auf die gezeichnet wird, nicht mehr überein.

Der andere von Espressif genannte Weg, den DMA in der Austastlücke neu zu starten, wurde gemessen zuerst versucht und wieder verworfen: das Gerät reagierte danach spürbar träge, während der Zwischenpuffer nichts davon kostet. Er belegt 21 KB des internen Speichers, von 155 auf 134 KB frei.

Der direkte Betrieb mit avoid_tearing steht unverändert, ebenso die zwei Bildpuffer im PSRAM. Der Zähler an der Übergabe zum Panel steht ebenfalls noch, misst aber im direkten Betrieb immer ein volles Bild, weil dort der ganze Puffer übergeben wird und nicht der Teil, der sich geändert hat. Was gezeichnet wurde, sagt er nicht.

8. Was daraus nicht folgt

Diese Zahlen gelten für ein Gerät, zwei Bibliotheken in je einer Einstellung und einen Tag. Sie sagen nicht, dass eine Oberfläche auf einem Controller-Board grundsätzlich so langsam ist. Sie sagen, was dieser ESP32-S3 an Bildpunkten je Sekunde rechnet, und dass zwei unabhängig gebaute Software-Renderer denselben Wert erreichen.

Sie sagen auch nicht, dass LVGL allgemein schneller ist als Slint. Verglichen wurden zwei Zustände: derselbe Ablauf über dieselben Seiten, jeweils in der Einstellung, die für diesen Chip nahe liegt. Beim Gitter vergleicht die Zahl zwei verschiedene Verfahren, nämlich eingebettete Bilder gegen einen Decoder zur Laufzeit, und nicht zwei Fassungen desselben Verfahrens. Was Slint mit einem Laufzeit-Decoder leisten würde, ist unbekannt, weil die geprüfte Komponente für diesen Chip keinen mitbringt.

Und der Eindruck beim Bedienen ist keine Messung. Er stammt von einer Person, an einem Tag, aus einem Vergleich, in dem eine Seite ihr Rollverhalten mitbrachte und die andere ein nachgebautes hatte. Er ist notiert, weil er die Entscheidung mitträgt, und er ist ausdrücklich keine Zahl.

Sie sagen auch nicht, dass die Albumansicht der Mediathek nicht geht. Gemessen wurde ein Gitter aus zwölf Kacheln, das gerollt wird, und das kommt im Entwurf nicht vor: dort stehen vier Cover in einer Reihe, die einen Bildschirm füllt und steht. Was die Messung entscheidet, ist allein die Frage, wie man von den ersten vier Alben zu den nächsten kommt, und die Antwort lautet blättern.

Und sie sagen nichts über ein anderes Board. Dieses ist bewusst das schwächste, das für dieses Projekt in Frage kommt. Was hier trägt, trägt auf einem stärkeren erst recht, und jede Optimierung, die hier nötig ist, ist dort geschenkt.