TurboPixel Framebuffer Compression¶

Overview¶

TurboPixel is a fixed-ratio, lossy compression format for the final rendered bitmap on supported SF32 devices. It is part of the display path: extDMA compresses the bitmap, and the display controller decompresses TurboPixel as it transfers pixels to the panel.

TurboPixel is not an asset-storage format and does not replace eZip. eZip losslessly compresses source assets before they are read from storage; TurboPixel compresses the final rendered bitmap to reduce the PSRAM capacity and PSRAM bandwidth required by framebuffer traffic.

For the complete graphics flow and the position of TurboPixel relative to eZip, ePicasso, and the display controller, see Graphics Overview. This page focuses on TurboPixel's compression behavior, integration trade-offs, and availability.

Read this page when framebuffer capacity or display-read traffic is the bottleneck on an SF32LB55x, SF32LB56x, or SF32LB58x design. It helps product and firmware engineers weigh predictable PSRAM savings against lossy image quality; it is not a substitute for eZip asset compression.

Fixed-Ratio and Lossy by Design¶

TurboPixel has two defining properties:

• Fixed ratio for a selected configuration. The input pixel format and compression setting determine the nominal factor; it does not vary with image detail. The required allocation also depends on row alignment and chunking. Use the selected chip and SDK's sizing rules rather than a ratio copied from another configuration.
• Lossy compression. A TurboPixel-decompressed bitmap is not guaranteed to reproduce every original pixel value. The format trades some image fidelity for predictable reductions in PSRAM use and PSRAM traffic.

Lossy compression is often a sensible trade in a constrained embedded display system, but it is a product decision. Evaluate real screens at the target panel resolution, color depth, viewing distance, and refresh behavior rather than judging quality from a generic test image.

Framebuffer Measurement Template¶

Use this section to record measured TurboPixel results for one representative display resolution and SDK configuration. Unlike the eZip file-size comparison, this is a framebuffer allocation and PSRAM-traffic comparison: TurboPixel operates after rendering, not on the source asset file.

Include both opaque and alpha-blended screens. Alpha blending normally happens before TurboPixel, when the renderer composites foreground and background pixels into the final framebuffer. A screen that contains translucent icons, text, shadows, or layers can still produce an opaque RGB565 final framebuffer; record that distinction rather than treating the presence of alpha in source assets as an alpha channel in the compressed framebuffer.

For each valid TurboPixel path, calculate Relative to Uncompressed as TurboPixel framebuffer bytes ÷ uncompressed framebuffer bytes × 100%. The expected allocation follows the applicable fixed ratio, but the exact ratio, supported formats, alignment, refresh policy, and measured PSRAM traffic must come from the selected chip's documentation, SDK, and target-hardware test. Record visual acceptance separately: a fixed allocation ratio does not guarantee identical artifacts across opaque, text-heavy, gradient, and alpha-blended content.

Why Use TurboPixel¶

Reduce Framebuffer Storage¶

A full framebuffer can occupy substantial PSRAM at high resolution or with multiple draw buffers. TurboPixel reduces the allocation for the compressed final bitmap, which can leave more memory for UI assets, audio, application data, or other surfaces.

Budget peak live memory, not just that bitmap. An uncompressed render buffer, compressed display buffer, compression workspace, and double-buffered copies may coexist. Their sizes and lifetimes determine whether the complete design actually needs less PSRAM.

Reduce Display-Read Traffic¶

The display controller reads fewer bytes from a compressed framebuffer before decompression, reducing display-read traffic and contention with CPU, ePicasso, DMA, audio, and wireless activity.

That is not the total memory-traffic saving. Rendering still writes pixels, and compression reads its input and writes its output. Measure those transfers and their overlap with display reads. For frequently redrawn screens, compression overhead may offset the read savings; for repeatedly displayed frames, the balance can be different. Measure system energy as well as bandwidth.

Make Budgeting Predictable¶

For a fixed pixel format and compression setting, content changes do not change the nominal ratio. Use the SDK's compressed-row sizing and alignment rules to allocate buffers, then include all render, compression, and display reads/writes in the bandwidth budget. Keep panel-transfer bytes separate: TurboPixel is decompressed before panel output and does not automatically reduce that transfer.

Quality and Integration Trade-Offs¶

TurboPixel should be validated as part of the complete display design:

• Test text, thin lines, gradients, icons, photographs, animations, and high-contrast UI elements for visible artifacts.
• Confirm the color format, buffer alignment, extDMA path, and display-controller configuration supported by the chosen device and SDK.
• Measure frame time, PSRAM bandwidth, UI latency, and power under combined display, Bluetooth, audio, and AI workloads.
• Keep an uncompressed path available during bring-up so that image-quality and driver issues can be isolated.
• Do not present TurboPixel as lossless, even when artifacts are not visible in a particular UI.

SDK Integration Checks¶

The referenced extDMA guide lists ten nominal compression levels, while the referenced SDK sizing implementation supports levels 1, 2, and 3. Do not assume all documented levels are accepted by your build. Validate the selected setting and use the matching row-size calculation; an unsupported value can fall back to a different setting in a helper.

The extDMA guide lists RGB565, RGB888, and ARGB8888 inputs. Input support alone does not guarantee an alpha-preserving compressed display path. The LCDC branch without its dedicated layer-0 decompression register accepts RGB565/RGB888 for compressed layers; check the branch used by the selected chip. In the referenced LCDC driver, compression is enabled on layer 0 through HAL_LCDC_LayerSetCmpr.

The current OpenSiFli LCDC header defines the compressed-layer support macro only when HAL_EXTDMA_MODULE_ENABLED is enabled; its family guard excludes SF32LB52x and SF32LB57x. The header defines maximum compressed-layer widths of 512 pixels for SF32LB55x/SF32LB56x and 1024 pixels for SF32LB58x. These are compressed-layer integration limits, not universal panel-resolution limits. A source comment also notes that the LCPU path is not enabled.

SF32LB55x needs an integration caveat. The current OpenSiFli LCDC header defines the compressed-layer macro when HAL_EXTDMA_MODULE_ENABLED is enabled, but its comment notes that the LCPU path is not enabled. The published SDK LCDC capability table marks compressed-layer decompression unsupported on 55x, while the SF32LB55x datasheet describes TurboPixel and LCD-controller decompression. A compile-time macro does not prove that the complete display path has been validated. Treat 55x support as conditional and verify the exact SDK revision, core, build configuration, and target hardware; do not infer runtime support from the macro alone.

Keep renderer, extDMA, and display-controller buffer ownership separate. Wait for rendering before compression, for compression before display use, and for display use to finish before reusing that buffer. With cacheable shared memory, clean CPU-written input before hardware reads, prepare destination cache lines so dirty data cannot overwrite hardware output, and invalidate after completion before CPU reads it. Respect cache-line boundaries and neighboring data. Compression completion is not panel-transfer completion.

The extDMA source address, destination address, and transfer length must be 4-byte aligned. Follow the selected SDK's row stride, chunking, and buffer-sizing rules; dividing raw frame bytes by a nominal ratio is not sufficient.

Availability in the SF32 Family¶

TurboPixel is documented for the following SF32 families:

This table records documented family-level availability, not a promise for every package, panel interface, pixel format, SDK version, or board configuration. Confirm the exact target before making a memory or bandwidth commitment.

Key Takeaways¶

• TurboPixel is a fixed-ratio, lossy final-framebuffer compression format.
• extDMA produces TurboPixel from the rendered bitmap; the display controller decompresses it on the panel path.
• Its main purpose is to reduce framebuffer storage and display-read traffic; confirm the savings for the complete buffer and transfer pipeline.
• TurboPixel is documented for SF32LB55x, SF32LB56x, and SF32LB58x. For 55x, the current header exposes the compressed-layer macro when extDMA is enabled but notes that the LCPU path is not enabled; the published feature table marks 55x unsupported. Treat it as conditional and validate the complete display path. The current source excludes SF32LB52x and SF32LB57x; confirm any other target individually.
• TurboPixel complements eZip: eZip is lossless asset compression, while TurboPixel is lossy compression for the final bitmap.

Primary References¶

• extDMA guide
• Compression sizing implementation
• extDMA API
• LCDC support guards
• Current OpenSiFli LCDC compressed-layer guard
• Generated SDK LCDC capability table
• LCDC layer implementation
• Product briefs: SF32LB55x, SF32LB56x, SF32LB58x

Last updated: 2026-10-10