How Does Real-Time Rendering Work in Embedded GUI?

The most effective optimisation in Sparklet's real-time pipeline is dirty-region rendering — restricting per-frame pixel operations to only the screen areas that have actually changed since the last rendered frame.

Every Sparklet widget maintains a dirty flag. When a widget property changes — a gauge value updates, a button transitions from normal to pressed, an animation frame advances — the widget sets its dirty flag and records its bounding rectangle as requiring repaint. Property changes that do not affect visual output (e.g., setting a value to the same value it already holds) do not set the dirty flag.

Before each render frame, the GDI layer collects all dirty bounding rectangles from the widget tree and merges overlapping regions into a minimal union. Only pixels within this union are recomputed. On typical industrial HMI screens — static background, a few live data fields — 80–95% of the screen area is skipped every frame. On a WVGA display at 60 fps, this represents approximately 1.8 billion pixel operations per second avoided.

Dirty-region rendering also benefits hardware-accelerated configurations. Even with DMA2D or D/AVE2D available, initiating an accelerator transfer for unchanged regions consumes DMA bandwidth. Skipping those regions frees the bus for concurrent SPI communication or ADC sampling. Rendering engine overview →

Standard double-buffered rendering requires two full-screen framebuffers: one displayed by the LCD controller while the other is rendered into. On a WVGA (800×480) display at 16-bit colour depth, each framebuffer occupies 768 KB — two framebuffers consume 1.5 MB, more RAM than many MCUs have available.

Sparklet's partial buffer mode eliminates the requirement for a second full-size framebuffer. Instead of rendering an entire frame off-screen, the GDI renders to a small scan-line buffer — for example, 100 lines tall — and flushes that band to the display via DMA while simultaneously rendering the next band. This pipeline overlap means the CPU is never idle waiting for a DMA transfer to complete.

The RAM saving is substantial. A 100-line partial buffer for WVGA at 16-bit depth requires 160 KB instead of 768 KB — saving 608 KB. On MCUs with 512 KB internal SRAM, this is the difference between a feasible design and an infeasible one.

Both full-buffer (tear-free) and partial-buffer (RAM-saving) modes are available as a build configuration option. Sparklet supports vsync-locked flush on platforms where the LCD controller provides a vsync interrupt, minimising tearing risk in partial-buffer mode. Memory footprint benchmarks by platform →

In an RTOS environment, multiple tasks may want to update widget properties concurrently: a CAN bus receive task updates a speed value; a timer task updates a clock widget; a touch handler processes a button press. If any of these tasks calls Sparklet's widget API directly from their own context while the rendering task reads widget state, race conditions result in visual corruption and unpredictable behaviour.

Sparklet prevents this with a single-task rendering model. All Sparklet API calls — widget property updates, screen switches, animation triggers — must originate from the Sparklet rendering task. Other RTOS tasks that need to update UI data post messages to an RTOS queue; the rendering task drains this queue at the start of each frame, before state machine execution and rendering begin.

This architecture provides three guarantees: no race conditions on widget state (only one task ever writes to it); input events captured in interrupt context are queued and processed in a deterministic order relative to application data updates; and frame budget calculation is accurate — the rendering task's CPU usage includes all UI-related work, enabling straightforward RTOS task priority tuning. The EXEC layer drives this single-task loop on every platform — bare-metal main loop or RTOS task, same API. RTOS support details →