feat(core): transparent ARGB compositing with retained raster layer passes - #248
Draft
odex21 wants to merge 2 commits into
Draft
feat(core): transparent ARGB compositing with retained raster layer passes#248odex21 wants to merge 2 commits into
odex21 wants to merge 2 commits into
Conversation
ARGB targets now clear to fully transparent and write straight color + coverage into transparent destination pixels, so hosts can composite the scene over their own background layers. When the destination already holds content, blends use true straight-alpha src-over: out_a = a + dst_a * (1 - a) out_rgb = (src * a + dst_rgb * dst_a * (1 - a)) / out_a instead of the previous "blend against opaque black and force alpha 255", which flattened semi-transparent destination pixels (glyph edges over another layer, translucent backgrounds) on layered surfaces. Opaque destinations reduce to the previous mix (same rgb, alpha 255), so RGBA/RGB565 targets and existing hosts are unchanged. The ARGB memory layout test now seeds a fullscreen opaque rect so both targets carry content in every pixel under the transparent-clear contract; a reference-math test pins the semi-transparent src-over result.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two commits on top of upstream main (f658cd0):
rasterCacheproperty (id 143) plusUi::draw_retained(), returning ordered Draw/Layer passes. Translation-only layer roots keep stable layer-local DrawLists, so capable hosts can retain pixels and only move composition coordinates; the flatUi::draw()ABI stays byte-compatible.Motivation
The ESP32-P4 product host composites a transparent UI layer over a fluid background and scrolls a retained lyric layer by translation only. The previous PSP-era "blend against opaque black and force alpha 255" flattened semi-transparent destination pixels on layered surfaces; the retained passes let hosts skip re-rasterization when only the layer position changes.
Verification
cargo test: commit 1 = 111/111, tip = 114/114 (each commit individually green)spec.ts<-> generatedspec.rs)Ui::draw()output unchanged (existing layout/golden tests)Performance (measured on the ESP32-P4 product host)
On-device A/B with a minimal scrolling-list app (no audio/WS/cover/fluid), identical code except
rasterCache0 vs 1, sampled via the host serial perf probe (1 s windows, medians):Retained layers cut per-frame raster cost by ~95% (13.1 ms -> 0.63 ms) and raise fps by ~15%; the remaining wall is the host-side retained composite chain (blend + pipeline wait), not core raster. Numbers are host-specific; the core-level benefit is the stable layer-local DrawList verified by tests.
Notes
damage.rs/draw.rs/lib.rs/raster.rs/tests.rs) but with unrelated mechanisms; any conflicts would be mechanical.docs/RETAINED_LAYERS.md; property id 143 is append-only (next free after 142).