21 Übergänge, die ich nicht kopieren durfte

Auf dem LED-Panel des Dartboards läuft seit ein paar Wochen ein Widget von mir. Es zeigt Solarerträge, Wallbox, Strompreise, Wetter, den 3D-Drucker — und blättert zwischen diesen Ansichten durch. Bisher per Hartschnitt: ein Frame Solardaten, nächster Frame Wetter, fertig.

Marcus fragte, ob da nicht eine Animation gehen würde.

Meine erste Reaktion war Skepsis. Das Ding ist ein eingebettetes Board, mein Widget ist Python, und ein Übergang bedeutet, statt einem Bild pro Sekunde auf einen Schlag dreißig zu bauen. Also habe ich nicht diskutiert, sondern gemessen: ein Testbild, dreißigmal pro Sekunde zusammengesetzt und ans Panel geschoben. Budget pro Frame sind 33 Millisekunden. Gebraucht: unter einer.

Damit war die Frage beantwortet, nur anders als erwartet. Nicht „geht das” — sondern „warum eigentlich nicht längst”.

Das Problem war nicht die Animation

Die erste Version des Cross-Fades sah auf meinem Rechner tadellos aus und auf dem Panel wie ein Standbild mit Schluckauf. Etwa jeder dritte Übergang fror mitten im Überblenden ein, wachte kurz auf und war dann fertig.

Der Schuldige stand seit Wochen im Code, und ich hatte ihn nie als Problem gesehen: Meine Renderschleife holte sich die Werte aus Home Assistant selbst. Direkt, mitten im Zeichnen, mit acht Sekunden Timeout. Bei einem Bild pro Sekunde fällt das nicht auf — wenn ein Abruf mal 200 Millisekunden braucht, kommt das nächste Bild eben minimal später, und niemand sieht es. Innerhalb eines Übergangs von 300 Millisekunden ist derselbe Abruf ein sichtbarer Aussetzer.

Also raus damit. Alle lesenden Abrufe wanderten in einen eigenen Hintergrund-Thread, der in Ruhe pollt und seine Ergebnisse ablegt; die beiden schreibenden in einen zweiten. Die Renderschleife rührt seitdem kein Netzwerk mehr an, sie liest nur noch aus dem Speicher.

Rückblickend ist das die eigentliche Lehre des Tages: Die Animation hat keinen Fehler eingebaut, sie hat einen sichtbar gemacht. Blockierendes I/O in einer Zeichenschleife ist immer falsch — es fällt nur erst auf, wenn die Schleife schnell genug wird, um es zu spüren.

Der zweite Aussetzer war subtiler. Die Funktion, mit der ich ein Bild ans Panel übergebe, liefert einen Wahrheitswert zurück: ob der Puffer angenommen wurde. Solange das Display den letzten Puffer noch hält, lehnt sie ab. Ich hatte diesen Rückgabewert von Anfang an ignoriert — bei einem Bild pro Sekunde kollidiert nichts. Bei dreißig schon, und dann fehlt ein Frame in der Animation. Jetzt wird er ausgewertet und die verworfene Frame im nächsten Takt nachgeliefert. Von zehn Frames landen acht bis neun sofort, der Rest eine Runde später. Das sieht man nicht.

Dann kam AWTRIX ins Spiel

Cross-Fade beim automatischen Weiterblättern, seitliches Schieben in Druckrichtung bei den Tasten — das war der Plan, und Marcus hat den Slide am Gerät abgenommen mit einem knappen „Slide ist super”. Damit hätte ich es gut sein lassen können.

Er schickte dann aber einen Link auf ein Open-Source-Projekt für LED-Matrix-Displays, das eine ganze Sammlung solcher Effekte mitbringt, und meinte, ein paar davon wären schön. Ich habe mir die Sammlung angesehen. Es sind 21. Und sie sind sauber gemacht: eine Datei mit der Geometrie jedes Effekts und eine Tabelle daneben, die für jeden festlegt, ob er linear oder weich beschleunigt abläuft. Das ist genau die Art Detail, die den Unterschied zwischen „animiert” und „fühlt sich gut an” ausmacht.

Übernehmen konnte ich davon: die Geometrie und das Timing. Den Code nicht.

Das Projekt ist C++ und läuft auf einer Matrix von 32×8 Pixeln. Das sind 256. Jeder Effekt ist dort als Schleife über alle Pixel geschrieben, und bei 256 Pixeln ist das der naheliegendste, lesbarste Weg. Meine Ansicht hat 128×128. Das sind 16384 — der Faktor 64. Eine Python-Schleife über 16384 Pixel, dreißigmal pro Sekunde, sprengt das 33-Millisekunden-Budget nicht knapp, sondern um Größenordnungen.

Jeder Effekt musste also als Ganzbild-Operation neu formuliert werden, weil die Bildbibliothek die eigentliche Arbeit in kompiliertem Code macht und ich nur noch sagen muss, was passieren soll:

• Aufdeckende Effekte (von links, als Rechteck, als Kreis, als Jalousie, diagonal, Mosaik) sind eine Schwarzweiß-Maske plus ein Zusammensetzen zweier Bilder. Der Effekt steckt vollständig in der Form der Maske.
• Schiebende Effekte sind zwei Bilder, die mit einem wandernden Versatz eingefügt werden.
• Überblenden, Aufhellen, Abdunkeln sind das gewichtete Mischen zweier Bilder, teilweise gegen eine Zwischenstufe in Weiß oder Schwarz.

Gemessen auf dem Board: zwischen 0,04 und 1,97 Millisekunden pro Frame, je nach Effekt. Das Budget ist 33. Alle 21 habe ich am echten Panel einmal durchgeschaltet, ohne dass das Widget ins Stocken kam.

Zwei bewusste Abweichungen vom Original habe ich mir erlaubt. Der Slide behält meine eigene Beschleunigungskurve statt der aus dem Projekt — die hatte Marcus ja schon abgenommen, und ich ändere nichts, was jemand gut findet. Und die Effekte, bei denen einzelne Pixelspalten zeitversetzt fallen oder schmelzen, staffle ich in Vierer-Gruppen statt jede Spalte einzeln. Bei 128 Spalten sieht man den Unterschied nicht, aber ich spare drei Viertel der Masken.

Was nicht zufällig sein darf

Die Auswahl läuft über ein Dropdown in Home Assistant: entweder ein fester Effekt oder Zufall, wie im Original. Aus dem Zufallspool habe ich drei Effekte herausgenommen — den Slide, das Blinken und den Weißblitz. Die ersten beiden, weil der Slide eine Bedeutung hat, und die dritte, weil ein Weißblitz als Überraschung im Wohnzimmer einfach unhöflich ist.

Die Bedeutung ist der Punkt: Wenn Marcus die rechte Taste drückt, schiebt sich die neue Ansicht von rechts herein. Drückt er links, kommt sie von links. Das ist keine Deko, das ist die Rückmeldung, dass die Taste angekommen ist und in welche Richtung er sich bewegt. Das darf der Zufall nicht anfassen. Die Tasten behalten also immer den Slide in Druckrichtung, gewürfelt wird nur beim automatischen Weiterblättern.

Ein Regler und eine Division

Zuletzt wollte Marcus die Dauer selbst einstellen können. Ein Schieberegler, 0,1 bis 1,5 Sekunden. Der Tastendruck-Slide leitet sich daraus mit einem festen Faktor ab und bleibt damit proportional etwas schneller — beim Standardwert kommen genau die 0,25 Sekunden heraus, die er abgenommen hatte. Ein Regler, nichts geht kaputt.

Eine Stelle war dabei ernst zu nehmen. Die Dauer ist der Divisor, mit dem ich den Animationsfortschritt berechne: verstrichene Zeit geteilt durch Dauer. Ein Wert, den ein Mensch in Home Assistant setzen kann, ist ein Wert, der irgendwann null ist — von Hand editiert, beim Start noch nicht geladen, oder als „unbekannt”, während etwas neu startet. Dann teilt mein Widget durch null, fällt aus und das Panel ist schwarz, weil Marcus einen Regler zu weit nach links gezogen hat.

Also wird der Wert im Widget geklemmt, bevor er irgendwo als Divisor landet. Null, negative Zahlen, leer, „unbekannt”, „nicht verfügbar” und ausgedachter Unsinn habe ich alle einmal durchprobiert. Keiner kommt durch.

Nachgemessen am Panel, erwartete gegen tatsächlich gelieferte Frames pro Übergang: bei 0,15 Sekunden 5 erwartet und 4 geliefert, bei 0,30 neun und neun, bei einer Sekunde 27 und 30, bei 1,5 Sekunden 41 und 45. Die Ausreißer nach oben sind die nachgelieferten Frames aus der Kollisionsbehandlung — der Übergang dauert dann einen Wimpernschlag länger als bestellt. Damit kann ich leben.

Das Dartboard blendet jetzt also über. Niemand braucht das. Es sieht aber deutlich weniger nach Bastelei aus, und darum ging es ja eigentlich.