Ottimizzazione grafica degli asset nei sistemi embedded

Indice dei contenuti

Perché ottimizzare le risorse grafiche?

L’ottimizzazione delle risorse grafiche nei sistemi embedded consiste principalmente nel bilanciare la qualità visiva con le limitate risorse di sistema. A differenza degli ambienti desktop o mobili, le piattaforme embedded – soprattutto quelle basate su MCU – operano sotto stretti vincoli in termini di RAM, memoria, potenza di elaborazione e larghezza di banda della memoria. Anche nei sistemi MPU/Linux più capaci, queste risorse non sono illimitate e possono diventare rapidamente dei colli di bottiglia quando si tratta di interfacce utente complesse.

Per questo motivo, le risorse grafiche come immagini, font e animazioni non possono essere trattate come elementi “liberi”. Le loro dimensioni, il loro formato e la loro struttura hanno un impatto diretto sulle prestazioni del sistema, sulla reattività e talvolta anche sulla fattibilità del prodotto. L’ottimizzazione non è quindi una fase di perfezionamento opzionale, ma una parte fondamentale della progettazione di GUI embedded.

In pratica, ottimizzare le risorse significa ridurre l’ingombro di memoria, minimizzare i trasferimenti di dati e diminuire i costi di rendering, mantenendo una qualità visiva accettabile. Le tecniche e le priorità specifiche dipendono dalla piattaforma di destinazione e dai suoi principali colli di bottiglia, che questo articolo analizzerà in dettaglio.

Di seguito troverai alcuni metodi popolari per ottimizzare le risorse grafiche:

1. Riduzione della profondità del colore
2. Compressione delle attività
3. Pre-rendering e appiattimento
4. Ottimizzazione della risoluzione e della scalatura
5. Ridisegno parziale
6. Streaming di asset dalla memoria esterna

Riduzione della profondità del colore

Ridurre il formato dei pixel (ad esempio ARGB8888 → RGB565, L8, A4) è uno dei modi più efficaci per ridurre l’utilizzo della memoria e la larghezza di banda. Un minor numero di bit per pixel si traduce direttamente in risorse più piccole e in trasferimenti più rapidi al framebuffer.

Questa tecnica è particolarmente importante nelle MCU, dove la larghezza di banda della memoria RAM e della memoria flash è limitata. Anche nei sistemi MPU, può ridurre in modo significativo la pressione della larghezza di banda nelle applicazioni che richiedono l’uso dell’interfaccia utente.

Il principale compromesso è la riduzione della qualità visiva, in particolare le bande di colore e la limitata precisione dell’alfa.

Il meglio quando:

• Le dimensioni della RAM o del framebuffer sono un vincolo
• la larghezza di banda del display è un collo di bottiglia

Compressione delle attività

La compressione riduce l’impronta di archiviazione delle risorse grafiche, consentendo di inserire più contenuti in una memoria limitata. Gli approcci più comuni vanno dal semplice RLE a schemi basati su LZ o formati specifici per le immagini.

Nelle MCU, la compressione è spesso necessaria a causa degli stretti vincoli della Flash. Tuttavia, la decompressione introduce un overhead della CPU e talvolta richiede buffer temporanei nella RAM.

La decisione chiave di progettazione consiste nel bilanciare il risparmio di spazio di archiviazione con il costo del tempo di esecuzione.

Il meglio quando:

• La memoria flash/storage è limitata
• La CPU ha spazio sufficiente per la decompressione

Pre-rendering e appiattimento

Invece di renderizzare elementi complessi dell’interfaccia utente (gradienti, ombre, effetti) in fase di esecuzione, è possibile prerenderizzarli in bitmap statici. Questo sposta il lavoro dalla CPU alla memoria.

Si tratta di un approccio comune nei sistemi basati su MCU senza accelerazione GPU, dove il tempo di rendering prevedibile è fondamentale.

Il compromesso è un maggiore utilizzo di Flash e una minore flessibilità: ogni modifica visiva richiede la rigenerazione delle risorse.

Il meglio quando:

• La CPU è un collo di bottiglia
• L’interfaccia utente è per lo più statica

Ottimizzazione della risoluzione e della scalatura

L’utilizzo di risorse che corrispondono alla risoluzione di destinazione evita il ridimensionamento del runtime, che può essere costoso in termini di CPU o di larghezza di banda della memoria.

Sui sistemi vincolati, anche le semplici operazioni di ridimensionamento possono diventare un problema di prestazioni, soprattutto se applicate a più elementi dell’interfaccia utente per fotogramma.

Preparare gli asset con l’esatta risoluzione (o con un insieme limitato di risoluzioni) garantisce prestazioni prevedibili e un minore utilizzo di risorse.

Il meglio quando:

• La CPU o la larghezza di banda sono limitate
• Il layout dell’interfaccia utente è fisso o prevedibile

Ridisegno parziale

Invece di ridisegnare l’intero schermo a ogni fotogramma, vengono aggiornate solo le regioni che sono cambiate. In questo modo si riduce notevolmente la quantità di dati trasferiti al display per ogni fotogramma.

In molti sistemi embedded, la larghezza di banda della memoria – non la CPU – è il collo di bottiglia principale. Il ridisegno parziale affronta direttamente questo problema riducendo al minimo i trasferimenti di pixel. L’uso del ridisegno parziale riduce la larghezza di banda della memoria e può anche ridurre il carico della CPU se non viene “ripreso” per gestire le “regioni sporche” che cambiano più spesso.

Sia TouchGFX che LVGL implementano questo concetto internamente utilizzando regioni sporche/invalidate.

Il meglio quando:

• la larghezza di banda dell’interfaccia del display è limitata (SPI, RGB, ecc.)
• Le modifiche all’interfaccia utente sono localizzate

Streaming di asset dalla memoria esterna

Lo streaming di risorse dalla memoria esterna si riferisce all’accesso alle risorse dell’interfaccia utente (come immagini, font o animazioni) direttamente dalla memoria non volatile (ad esempio Flash esterna, QSPI o un filesystem) in fase di esecuzione, senza copiarle permanentemente nella RAM.

Invece di precaricare intere risorse, il sistema legge solo le porzioni di dati necessarie e le elabora o renderizza al volo. In questo modo si riduce notevolmente l’utilizzo della RAM, pur consentendo l’uso di grafiche complesse e di grandi set di risorse.

Questa tecnica è comunemente utilizzata nei sistemi embedded con memoria limitata, in quanto consente di creare interfacce utente ricche sfruttando la larghezza di banda dell’archiviazione esterna piuttosto che affidarsi alla limitata RAM interna.

Il limite principale è la velocità di accesso: la larghezza di banda e la latenza della memoria esterna possono diventare un collo di bottiglia.

Il meglio quando:

• La RAM è molto limitata
• i beni sono grandi o numerosi

Conclusione

In pratica, l’ottimizzazione delle risorse grafiche non consiste tanto nell’applicazione di una singola tecnica quanto nella scelta della giusta combinazione in base ai vincoli del sistema. Ogni metodo si rivolge a un collo di bottiglia diverso – che sia la RAM, la dimensione della Flash, il carico della CPU o la larghezza di banda della memoria – e il miglioramento di un’area spesso va a scapito di un’altra.

Sui sistemi basati su MCU, l’attenzione è tipicamente rivolta alla minimizzazione dell’utilizzo della memoria e della larghezza di banda: la riduzione della profondità di colore, l’utilizzo della compressione, lo streaming degli asset e l’utilizzo del ridisegno parziale sono spesso essenziali. Sulle piattaforme MPU/Linux, anche se le risorse sono meno limitate, tecniche simili sono ancora importanti, soprattutto nelle applicazioni UI-heavy dove la larghezza di banda e l’efficienza della cache possono limitare le prestazioni.

Ciò che conta di più è identificare per tempo il collo di bottiglia principale e ottimizzare di conseguenza. In molte GUI embedded del mondo reale, questo si rivela essere la larghezza di banda della memoria piuttosto che le prestazioni della CPU. Capire questo aspetto aiuta a guidare decisioni come la selezione del formato dei pixel, la strategia di ridisegno e la struttura delle risorse.

In definitiva, un’ottimizzazione efficace si basa su compromessi. Non esiste un approccio universalmente ottimale, ma solo soluzioni che si adattano al meglio a una determinata piattaforma hardware, alla complessità dell’interfaccia utente e all’obiettivo di prestazioni.