Overview¶

Overview¶

This guide explains how to build responsive graphical user interfaces on SF32 devices. It focuses on the practical decisions that affect real products: display selection, framebuffer strategy, LVGL integration, ePicasso hardware acceleration, memory placement, and display refresh behavior.

SF32 devices are designed for compact AIoT and wearable products where the UI must feel smooth while the system still meets strict power, memory, and PCB-area targets. The graphics path separates resource handling, pixel composition, optional framebuffer compression, and panel output. Keeping those roles distinct is the key to choosing the right optimization.

Use this page when making the early UI architecture decisions that are expensive to reverse: panel and interface, framebuffer strategy, color depth, transparency, asset placement, and refresh policy. The linked Graphics articles then provide the implementation detail for a specific block in that flow.

SF32 Graphics Flow¶

The typical display-resource path is:

Source images, fonts, and animations
        │
        ▼
GraphicsTool converts supported resources to eZip or eZip-A
        │
        ▼
Compressed assets in NOR Flash, PSRAM, NAND, or file storage
        │
        ▼
eZip hardware decoder expands an asset when required
        │
        ▼
LVGL or another UI framework + graphics/display driver
        │
        ├── CPU fallback rendering
        │
        └── ePicasso pixel acceleration
        │
        ▼
Final rendered bitmap in a draw buffer or framebuffer
        │
        ├── Uncompressed display path
        │
        └── Optional: extDMA compresses it into TurboPixel
                    │
                    ▼
             TurboPixel framebuffer in PSRAM
        │
        ▼
Display controller transfers pixels to the panel
        │
        ▼
SPI / QSPI / 8080 / RGB / MIPI DSI / EPD / JDI panel

The path is configurable rather than mandatory: a product may not use eZip, ePicasso, TurboPixel, or a full framebuffer. Availability and connections depend on the selected device, SDK, display interface, panel, and driver configuration. In particular, TurboPixel is documented on SF32LB55x, SF32LB56x, and SF32LB58x; it is not available on SF32LB52x or SF32LB57x.

Application code describes UI state and behavior. The UI framework manages widgets, invalidation, and drawing. The graphics/display driver chooses CPU or ePicasso execution and coordinates buffers; the display controller owns panel transfer. For feature-specific implementation details, see ePicasso, eZip, and TurboPixel.

Choose the Display First¶

The display choice affects nearly every graphics decision. Before optimizing code, define the panel requirements clearly:

• Resolution.
• Color depth.
• Refresh rate.
• Interface type.
• Touch controller requirements.
• Backlight or display power rails.
• Whether partial refresh is supported.
• Whether the panel has internal GRAM.
• Whether low-power always-on display behavior is required.

A small SPI or QSPI AMOLED behaves very differently from an RGB panel, MIPI DSI panel, JDI memory display, or EPD panel. The same UI framework can target many display types, but the best buffer strategy and refresh policy will change.

For detailed interface selection, flush-path design, and panel bring-up, see Display Controller.

Pick the Right SF32 Device¶

Choose the chip based on the display and UI workload, not just CPU frequency.

The most important constraints are display interface, resolution, memory capacity, graphics accelerator generation, available pins, and power budget.

Framebuffer and Bandwidth Calculator¶

Estimate memory and transfer cost before choosing a panel or animation style:

framebuffer bytes = width x height x bytes_per_pixel
raw full-frame bandwidth = framebuffer bytes x frames_per_second

Examples:

These are raw pixel numbers before command overhead, alignment, cache maintenance, asset reads, blending, or other system traffic. If the product also runs Bluetooth audio, AI, or external PSRAM traffic, leave margin.

Understand Your Buffers¶

A UI is ultimately pixels in memory. The main buffer types are:

A full-screen framebuffer can be convenient, but it may consume too much SRAM on larger panels. For a 454 x 454 RGB565 display, a single full-screen buffer is about 412 KB. Two buffers double that. Higher color depths and larger displays grow quickly.

When memory is tight, use partial draw buffers and dirty-region updates. When animation is important and memory is available, full-screen or double-buffered strategies may make the UI smoother.

Choose Color Depth Carefully¶

Color depth affects visual quality, memory use, and bus bandwidth.

For most wearable and compact HMI products, RGB565 is a strong default unless the panel, UI quality target, or product requirements demand more.

Transparency, Alpha, and Layer Composition¶

Transparency is represented by an alpha factor: a value that specifies how strongly a foreground pixel contributes when it is drawn over a background pixel. Alpha is independent of RGB color channels. An opaque pixel has alpha 1 (or 255 in an 8-bit alpha channel); a fully transparent pixel has alpha 0.

For the common source-over operation, each output color channel is calculated as:

output = foreground × alpha + background × (1 − alpha)

For example, an icon pixel with 50% alpha contributes half of its color and leaves half of the background visible. Repeating this operation produces the visual stack of a UI: a background, images, text, translucent controls, shadows, and animation layers. The final composited bitmap then proceeds through the framebuffer and display-controller stages shown above.

RGB565 contains no alpha channel, so it is normally used for opaque draw targets and final framebuffers. Source assets or intermediate layers that need alpha commonly use a format with an alpha channel, such as ARGB8888, or a color image plus a separate alpha mask. The driver must use the actual formats supported by the SDK, display path, and selected accelerator.

Two alpha representations are common. With straight alpha, RGB describes the original color and alpha is applied during blending. With premultiplied alpha, RGB has already been multiplied by alpha; the source-over equation becomes output = premultiplied_foreground + background × (1 − alpha). Do not mix the two representations: treating straight-alpha data as premultiplied, or the reverse, causes dark or light halos around edges.

Alpha blending reads both foreground and destination pixels, then writes the result. It therefore increases memory traffic compared with a simple opaque copy or fill. Use ePicasso where the driver supports the selected blend operation and pixel formats; otherwise keep a CPU fallback. Limit full-screen translucent layers, update only invalidated regions, and avoid unnecessary intermediate surfaces when PSRAM bandwidth or power is tight.

Integrating LVGL¶

LVGL is a practical UI framework for SF32 devices because it provides widgets, styles, input handling, animation, invalidation, and display-driver hooks.

A typical LVGL integration needs:

• A display driver flush callback.
• One or more draw buffers.
• A tick source for LVGL timing.
• Input device drivers for touch, buttons, encoders, or gestures.
• Asset handling for images and fonts.
• Optional hardware acceleration hooks for ePicasso.

The display flush callback is the rendering/output boundary. Its controller and DMA behavior is covered in Display Controller.

LVGL Porting Decisions¶

Lock down these LVGL integration details before polishing screens:

A good LVGL port should let screen code stay declarative while the driver owns transfer, synchronization, acceleration, and cache behavior.

Using ePicasso Acceleration¶

ePicasso is useful when the UI contains operations that would otherwise require many repeated pixel calculations. Common candidates include:

• Rectangle fills.
• Image copy and blit operations.
• Alpha blending.
• Image scaling.
• Rotation or transformation of supported image regions.
• Layer composition.
• Pixel format conversion where supported by the driver.

A good port should accelerate common high-volume operations while keeping CPU fallback paths for unsupported cases. Do not assume every LVGL style effect or widget maps to hardware. Measure the actual screens that matter for the product.

When Acceleration Helps Most¶

ePicasso usually helps most when:

• Large regions are filled, copied, blended, scaled, or transformed.
• The UI uses transparent icons, text masks, shadows, overlays, or animated transitions.
• The CPU would otherwise spend a large part of each frame doing pixel loops.
• Memory placement and pixel formats match what the accelerator can handle efficiently.

When Acceleration May Not Help Much¶

Hardware acceleration may provide limited benefit when:

• The updated region is very small.
• The bottleneck is panel transfer bandwidth, not rendering.
• Assets require unsupported formats or expensive conversion.
• Buffers are placed in slow memory without enough bandwidth.
• Cache maintenance overhead dominates the operation.

Memory Placement Strategy¶

Graphics performance is often limited by memory movement. Place buffers intentionally:

• Put hot draw buffers in fast SRAM when possible.
• Keep large framebuffers in PSRAM only when SRAM is insufficient.
• Store large images and fonts in Flash or PSRAM, but consider access latency.
• Avoid repeatedly converting assets at runtime.
• Keep DMA-accessed buffers aligned according to SDK guidance.
• Use compressed or indexed assets when they reduce total bandwidth and decode cost.

If the CPU, ePicasso, DMA, display controller, or other peripherals share buffers, follow the SDK cache maintenance rules. Clean CPU-written buffers before hardware reads them. Invalidate buffers after hardware writes them and before the CPU reads them.

For partial refresh, panel-specific behavior, and the staged bring-up sequence, see Display Controller.

Asset Preparation¶

Good asset preparation can make a UI faster before any code optimization begins.

Use these rules of thumb:

• Match image dimensions to actual on-screen size.
• Avoid scaling large images every frame.
• Pre-render complex shadows, gradients, or backgrounds when possible.
• Use alpha only where transparency is needed.
• Prefer shared icon sets and font subsets.
• Remove unused glyphs from fonts.
• Keep frequently used assets in formats supported efficiently by the graphics path.

For multilingual products, font memory can dominate the UI budget. Plan font fallback, glyph subsets, and text layout early.

Animation Strategy¶

Smooth animation depends on frame budget, panel bandwidth, rendering cost, and power.

A practical approach:

• Animate only what users notice.
• Keep animated regions small.
• Prefer transforms or opacity changes that map well to acceleration.
• Avoid expensive full-screen blur, shadow, or transparency effects on every frame.
• Reduce frame rate for non-critical effects.
• Stop animations when the screen is dimmed, covered, or inactive.

A wearable UI does not need desktop-style animation everywhere. A few fast, clear transitions usually feel better than many effects that drain power or drop frames.

Graphics Validation Matrix¶

Use repeatable screens instead of subjective “smooth enough” checks:

Track render time, flush time, CPU load, and power for each screen. If only total frame time is measured, it is hard to know whether the bottleneck is LVGL, ePicasso, memory, or the panel interface.

Debugging Graphics Performance¶

When the UI is slow, identify the bottleneck before changing the design.

Measure these separately:

• LVGL render time.
• ePicasso operation time.
• Display flush time.
• CPU load.
• Memory bandwidth pressure.
• Power consumption during active, idle, and sleep states.

Common Mistakes¶

Avoid these early; they are expensive to fix late:

• Choosing a panel interface before estimating bandwidth.
• Using full-screen redraws for small UI changes.
• Storing all UI assets in slow memory without profiling.
• Using RGB888 when RGB565 is sufficient.
• Scaling large images every frame.
• Forgetting cache maintenance for hardware-shared buffers.
• Assuming ePicasso accelerates every UI operation automatically.
• Using too many timers or animations that keep the CPU awake.
• Ignoring touch latency while optimizing only frame rate.
• Waiting until PCB bring-up to validate panel initialization.

Bring-Up Checklist¶

Use this checklist when starting a new SF32 graphics project:

• Confirm display resolution, color depth, interface, and panel driver IC.
• Confirm the selected SF32 device supports the required display interface.
• Estimate framebuffer and draw-buffer memory requirements.
• Decide full-frame, partial, single-buffer, or double-buffer strategy.
• Bring up panel reset, power rails, backlight, and initialization sequence.
• Implement the LVGL tick, display flush, and input drivers.
• Verify basic fill, image, text, and touch behavior.
• Enable ePicasso acceleration where supported by the SDK and driver.
• Validate cache clean/invalidate behavior for shared buffers.
• Profile render time, flush time, CPU load, and power.
• Test worst-case screens, animations, Bluetooth activity, and sleep/wake paths.

Key Takeaways¶

• Start graphics design from the display interface, resolution, color depth, and refresh requirements.
• Use LVGL or a similar framework to manage widgets, invalidation, drawing, and input.
• Use ePicasso to accelerate common pixel operations, but keep CPU fallback paths.
• Optimize memory placement and buffer strategy as carefully as rendering code.
• Prefer partial refresh for bandwidth-limited panels and static wearable screens.
• Treat UI performance as a system problem involving CPU, ePicasso, memory, display controller, panel interface, touch, and power policy.