Grafische Asset-Optimierung in eingebetteten

Inhaltsübersicht

Warum sollten Sie grafische Assets optimieren?

Bei der Optimierung von grafischen Assets in eingebetteten Systemen geht es in erster Linie darum, die visuelle Qualität mit den begrenzten Systemressourcen in Einklang zu bringen. Im Gegensatz zu Desktop- oder mobilen Umgebungen arbeiten eingebettete Plattformen – insbesondere MCU-basierte – unter engen Beschränkungen in Bezug auf RAM, Speicher, Verarbeitungsleistung und Speicherbandbreite. Selbst auf leistungsfähigeren MPU/Linux-Systemen sind diese Ressourcen nicht unbegrenzt und können bei komplexen Benutzeroberflächen schnell zu Engpässen werden.

Aus diesem Grund können grafische Elemente wie Bilder, Schriftarten und Animationen nicht als „freie“ Elemente behandelt werden. Ihre Größe, ihr Format und ihre Struktur wirken sich direkt auf die Systemleistung, die Reaktionsfähigkeit und manchmal sogar auf die Machbarkeit des Produkts aus. Die Optimierung ist daher kein optionaler Verfeinerungsschritt, sondern ein grundlegender Bestandteil der Entwicklung eingebetteter GUIs.

In der Praxis bedeutet die Optimierung von Assets die Reduzierung des Speicherbedarfs, die Minimierung von Datenübertragungen und die Senkung der Rendering-Kosten bei gleichzeitiger Beibehaltung einer akzeptablen visuellen Qualität. Die spezifischen Techniken und Prioritäten hängen von der Zielplattform und ihren wichtigsten Engpässen ab, die wir in diesem Artikel genauer untersuchen werden.

Im Folgenden finden Sie einige gängige Methoden zur Optimierung von grafischen Assets:

1. Reduzierung der Farbtiefe
2. Asset-Komprimierung
3. Vor-Rendering und Verflachung
4. Optimierung von Auflösung und Skalierung
5. Teilweise neu gezeichnet
6. Asset-Streaming aus externem Speicher

Reduzierung der Farbtiefe

Die Verringerung des Pixelformats (z.B. ARGB8888 → RGB565, L8, A4) ist eine der effektivsten Möglichkeiten, die Speichernutzung und Bandbreite zu reduzieren. Weniger Bits pro Pixel führen direkt zu kleineren Assets und schnelleren Übertragungen in den Framebuffer.

Diese Technik ist besonders wichtig für MCUs, bei denen sowohl die RAM- als auch die Flash-Speicher-Bandbreite begrenzt ist. Selbst auf MPU-Systemen kann sie den Bandbreitendruck in UI-lastigen Anwendungen erheblich reduzieren.

Der Hauptnachteil ist die geringere visuelle Qualität – vor allem die Farbstreifen und die begrenzte Alpha-Präzision.

Am besten wann:

• Die Größe des RAM oder des Framebuffers ist eine Einschränkung
• Die Anzeigebandbreite ist ein Engpass

Asset-Komprimierung

Die Komprimierung verringert den Speicherbedarf von grafischen Assets, so dass mehr Inhalte in den begrenzten Speicher passen. Gängige Ansätze reichen von einfachem RLE bis hin zu LZ-basierten Verfahren oder bildspezifischen Formaten.

Auf MCUs ist eine Komprimierung aufgrund der engen Flash-Beschränkungen oft notwendig. Die Dekomprimierung führt jedoch zu einem CPU-Overhead und erfordert manchmal temporäre Puffer im RAM.

Die wichtigste Design-Entscheidung ist die Abwägung zwischen Speichereinsparungen und Laufzeitkosten.

Am besten wann:

• Flash/Speicherplatz ist begrenzt
• Die CPU hat genug Spielraum für die Dekomprimierung

Vor-Rendering und Verflachung

Anstatt komplexe UI-Elemente (Farbverläufe, Schatten, Effekte) zur Laufzeit zu rendern, können sie in statische Bitmaps vorgerendert werden. Dies verlagert die Arbeit von der CPU auf den Speicher.

Dies ist ein üblicher Ansatz in MCU-basierten Systemen ohne GPU-Beschleunigung, bei denen eine vorhersehbare Rendering-Zeit entscheidend ist.

Der Nachteil ist die erhöhte Flash-Nutzung und die geringere Flexibilität – jede visuelle Änderung erfordert eine Neugenerierung der Assets.

Am besten wann:

• CPU ist ein Engpass
• UI ist meist statisch

Optimierung von Auflösung und Skalierung

Durch die Verwendung von Assets, die der Zielauflösung entsprechen, wird eine Skalierung zur Laufzeit vermieden, die in Bezug auf CPU oder Speicherbandbreite teuer sein kann.

Auf eingeschränkten Systemen können selbst einfache Skalierungsoperationen zu einem Leistungsproblem werden, insbesondere wenn sie auf mehrere UI-Elemente pro Frame angewendet werden.

Das Vorbereiten von Assets in der exakten Auflösung (oder einer begrenzten Anzahl von Auflösungen) sorgt für eine vorhersehbare Leistung und einen geringeren Ressourcenverbrauch.

Am besten wann:

• CPU oder Bandbreite ist begrenzt
• Das UI-Layout ist fest oder vorhersehbar

Teilweise neu gezeichnet

Anstatt den gesamten Bildschirm bei jedem Bild neu zu zeichnen, werden nur die Bereiche aktualisiert, die sich geändert haben. Dadurch wird die Datenmenge, die pro Bild an das Display übertragen wird, erheblich reduziert.

In vielen eingebetteten Systemen ist die Speicherbandbreite – nicht die CPU – der primäre Engpass. Teilweises Neuzeichnen geht direkt darauf ein, indem es die Pixelübertragungen minimiert. Die Verwendung von partiellem Redraw reduziert die Speicherbandbreite und kann auch die CPU-Belastung verringern, wenn sie nicht zur Verwaltung von „schmutzigen Bereichen“, die sich häufiger ändern, „umfunktioniert“ wird.

Sowohl TouchGFX als auch LVGL implementieren dieses Konzept intern mit schmutzigen/ungültigen Regionen.

Am besten wann:

• Die Bandbreite der Displayschnittstelle ist begrenzt (SPI, RGB, etc.)
• UI-Änderungen sind lokalisiert

Asset-Streaming aus externem Speicher

Asset-Streaming aus dem externen Speicher bezieht sich auf den Zugriff auf UI-Ressourcen (wie Bilder, Schriftarten oder Animationen) direkt aus einem nichtflüchtigen Speicher (z.B. externes Flash, QSPI oder ein Dateisystem) zur Laufzeit, ohne sie dauerhaft in den RAM zu kopieren.

Anstatt ganze Assets im Voraus zu laden, liest das System bei Bedarf nur die benötigten Teile der Daten und verarbeitet oder rendert sie on the fly. Dadurch wird der RAM-Bedarf erheblich reduziert, während gleichzeitig die Verwendung komplexer Grafiken und großer Ressourcensätze möglich ist.

Diese Technik wird häufig in eingebetteten Systemen mit begrenztem Speicherplatz verwendet und ermöglicht reichhaltige Benutzeroberflächen, indem die Bandbreite des externen Speichers genutzt wird, anstatt sich auf den begrenzten internen RAM zu verlassen.

Die wichtigste Einschränkung ist die Zugriffsgeschwindigkeit – die Bandbreite des externen Speichers und die Latenzzeit können zu einem Engpass werden.

Am besten wann:

• RAM ist sehr begrenzt
• die Vermögenswerte sind groß oder zahlreich

Schlussfolgerung

In der Praxis geht es bei der grafischen Asset-Optimierung weniger um die Anwendung einer einzigen Technik als vielmehr um die Auswahl der richtigen Kombination auf der Grundlage der Systembeschränkungen. Jede Methode zielt auf einen anderen Engpass ab – sei es RAM, Flash-Größe, CPU-Last oder Speicherbandbreite – und die Verbesserung eines Bereichs geht oft auf Kosten eines anderen.

Auf MCU-basierten Systemen liegt der Schwerpunkt in der Regel auf der Minimierung der Speichernutzung und der Bandbreite: die Reduzierung der Farbtiefe, die Verwendung von Komprimierung, das Streaming von Assets und das partielle Redraw sind oft unerlässlich. Auf MPU/Linux-Plattformen sind die Ressourcen zwar weniger eingeschränkt, aber ähnliche Techniken sind immer noch relevant – insbesondere bei UI-lastigen Anwendungen, bei denen Bandbreite und Cache-Effizienz die Leistung begrenzen können.

Das Wichtigste ist, den primären Engpass frühzeitig zu erkennen und entsprechend zu optimieren. In vielen realen eingebetteten GUIs ist dies eher die Speicherbandbreite als die reine CPU-Leistung. Dieses Verständnis hilft bei Entscheidungen wie der Auswahl des Pixelformats, der Redraw-Strategie und der Asset-Struktur.

Letztlich geht es bei der effektiven Optimierung um Kompromisse. Es gibt keinen universell optimalen Ansatz – nur Lösungen, die am besten zu einer bestimmten Hardwareplattform, der Komplexität der Benutzeroberfläche und dem Leistungsziel passen.