Graphical asset optimization in embedded

Table of Contents

Why to optimize graphical assets?

Graphical asset optimization in embedded systems is primarily about balancing visual quality with limited system resources. Unlike desktop or mobile environments, embedded platforms – especially MCU-based ones – operate under tight constraints in terms of RAM, storage, processing power, and memory bandwidth. Even on more capable MPU/Linux systems, these resources are not unlimited and can quickly become bottlenecks when dealing with complex user interfaces.

Because of this, graphical assets such as images, fonts, and animations cannot be treated as “free” elements. Their size, format, and structure directly impact system performance, responsiveness, and sometimes even feasibility of the product. Optimization is therefore not an optional refinement step, but a fundamental part of designing embedded GUIs.

In practice, optimizing assets means reducing memory footprint, minimizing data transfers, and lowering rendering cost, while maintaining acceptable visual quality. The specific techniques and priorities depend on the target platform and its main bottlenecks, which this article will explore in more detail.

Below you will find few popular methods of optimizing graphical assets:

1. Reducing color depth
2. Asset compression
3. Pre-rendering and flattening
4. Resolution and scaling optimization
5. Partial redraw
6. Asset streaming from external memory

Reducing color depth

Lowering pixel format (e.g. ARGB8888 → RGB565, L8, A4) is one of the most effective ways to reduce memory usage and bandwidth. Fewer bits per pixel directly translate to smaller assets and quicker transfers to the framebuffer.

This technique is especially important on MCUs, where both RAM and flash memory bandwidth are limited. Even on MPU systems, it can significantly reduce bandwidth pressure in UI-heavy applications.

The main trade-off is reduced visual quality – most notably color banding and limited alpha precision.

Best when:

• RAM or framebuffer size is a constraint
• display bandwidth is a bottleneck

Asset compression

Compression reduces the storage footprint of graphical assets, allowing more content to fit in limited memory. Common approaches range from simple RLE to LZ-based schemes or image-specific formats.

On MCUs, compression is often necessary due to tight Flash constraints. However, decompression introduces CPU overhead and sometimes requires temporary buffers in RAM.

The key design decision is balancing storage savings against runtime cost.

Best when:

• Flash/storage is limited
• CPU has enough headroom for decompression

Pre-rendering and flattening

Instead of rendering complex UI elements (gradients, shadows, effects) at runtime, they can be pre-rendered into static bitmaps. This shifts work from CPU to storage.

This is a common approach in MCU-based systems without GPU acceleration, where predictable rendering time is critical.

The trade-off is increased Flash usage and reduced flexibility – any visual change requires regenerating assets.

Best when:

• CPU is a bottleneck
• UI is mostly static

Resolution and scaling optimization

Using assets that match the target resolution avoids runtime scaling, which can be expensive in terms of CPU or memory bandwidth.

On constrained systems, even simple scaling operations can become a performance issue, especially when applied to multiple UI elements per frame.

Preparing assets in the exact resolution (or a limited set of resolutions) ensures predictable performance and lower resource usage.

Best when:

• CPU or bandwidth is limited
• UI layout is fixed or predictable

Partial redraw

Instead of redrawing the entire screen every frame, only the regions that have changed are updated. This significantly reduces the amount of data transferred per frame to the display.

In many embedded systems, memory bandwidth – not CPU – is the primary bottleneck. Partial redraw directly addresses this by minimizing pixel transfers. Using partial redraw reduces memory bandwidth and can also reduce CPU load if it is not “reconsumed” to manage “dirty regions” that changes more often.

Both TouchGFX and LVGL implement this concept internally using dirty/invalidated regions.

Best when:

• display interface bandwidth is limited (SPI, RGB, etc.)
• UI changes are localized

Asset streaming from external memory

Asset streaming from external memory refers to accessing UI resources (such as images, fonts, or animations) directly from non-volatile storage (e.g. external Flash, QSPI, or a filesystem) at runtime, without permanently copying them into RAM.

Instead of preloading entire assets, the system reads only the required portions of data when needed and processes or renders them on the fly. This significantly reduces RAM usage while still allowing the use of complex graphics and large resource sets.

This technique is commonly used in embedded systems with constrained memory, enabling rich user interfaces by leveraging external storage bandwidth rather than relying on limited internal RAM.

The main limitation is access speed – external memory bandwidth and latency can become a bottleneck.

Best when:

• RAM is very limited
• assets are large or numerous

Conclusion

In practice, graphical asset optimization is less about applying a single technique and more about choosing the right combination based on system constraints. Each method targets a different bottleneck – whether it is RAM, Flash size, CPU load, or memory bandwidth – and improving one area often comes at the cost of another.

On MCU-based systems, the focus is typically on minimizing memory usage and bandwidth: reducing color depth, using compression, streaming assets, and relying on partial redraw are often essential. On MPU/Linux platforms, while resources are less constrained, similar techniques are still relevant – especially in UI-heavy applications where bandwidth and cache efficiency can limit performance.

What matters most is identifying the primary bottleneck early and optimizing accordingly. In many real-world embedded GUIs, this turns out to be memory bandwidth rather than raw CPU performance. Understanding this helps guide decisions such as pixel format selection, redraw strategy, and asset structure.

Ultimately, effective optimization is about trade-offs. There is no universally optimal approach – only solutions that best fit a given hardware platform, UI complexity, and performance target.