Scroll on 2018-class Android is scene-update and render-pass bound; needs retained translated-surface reuse and pass coalescing

[samoylenkodmitry]

Summary

With the accessibility bridge fixed (#497), scroll on a Huawei EVR-AL00 (Kirin 980, Mali-G76, 60 Hz, 1080×2244) is still far from 60 fps on glass-heavy pages. Measured with debug.cranpose.frame_telemetry, debug.cranpose.frame_stage_ms, and debug.cranpose.gpu_stats on device.

Numbers below were re-taken on a quiet device (2026-08-27). The original
filing measured cranscan while its on-device OCR (Qwen3-VL 8B) was still
running — the app settled at 442 % CPU before the scroll even started, so
the app's own inference was being charged to the framework.

Same page, same device, same build — only the background load differs:

	as filed (OCR running)	quiet device
fps	15–17	28.2
present p50	29–33 ms	13.5 ms
render p50	12–13 ms	8.1 ms

Wait for the app's own CPU to settle, and print what it settled at, before
trusting any on-device frame number.

The ranked causes below were re-verified, not re-derived. Pass count,
isolated-layer count, and the ~35 % layer-cache hit rate reproduce exactly on
a quiet device. Two of them came in worse than originally filed. Nothing in
the diagnosis changed — only the headline numbers.

cranscan Library page (receipt cards + liquid-glass headers), quiet device, clean idle_iters=0 window: 28.2 fps

• period p50 = 34.9 ms (~2 vsyncs)
• present p50 = 13.5 ms — swapchain blocking on the GPU (filed as 29–33 ms under OCR load)
• render (CPU encode) p50 = 8.1 ms (filed as 12–13 ms)
• update p50 = 4.7–5.3 ms; a11y sync p50 = 5.5–5.6 ms (gone after Gate the Android accessibility publish on assistive-tech state and batch it at Compose parity #497)
• GPU stats per frame: 35 render passes, 9 isolated layers, 7 live blurs, layer cache at 34.6 % hits with 1.78 MP of blurred offscreen content re-rendered every scrolled frame

Note that passes (35) and isolated layers (9) exceed the originally filed ranges (23–31 and 6–8). That part of the problem was understated, not overstated.

Demo Liquid tab (framework build incl. #497): 35–37 fps

• period p50 ≈ 26 ms, cpu p50 ≈ 25 ms
• update p50 = 10.4 ms, of which frame-stage-telemetry shows scene_ms 6.4–7.4 and layout 2.5–3.5
• render p50 ≈ 6 ms encoding 30–39 passes/frame, present p50 ≈ 7.5 ms
• shadow cache and glyph atlas: 100 % hits (not the problem)

What #497 does and does not buy

#497 removes the per-frame accessibility publish. On a same-package, same-data,
same-thermal-state A/B it takes sync p50 from 5.12/5.16 ms to 0.00 ms.

It does not improve frame rate, and should not be described as a perf fix:

baseline rep1  fps 41.60   sync p50 5.12
baseline rep2  fps 40.34   sync p50 5.16
patched        fps 40.55   sync p50 0.00

That is one noise band. Stage sums explain why: ~22.4 ms → ~19.4 ms against a
~16.1 ms vsync budget. The cut is real, but the frame misses the same vsync
either way. You do not get paid until you cross 16 ms. #497 is worth landing as
a correctness and battery fix — publishing an accessibility tree every frame
when nothing is listening is pure waste — but the fps work is entirely below.

Ranked causes

1. Scene update re-emission (~7 ms CPU/frame). During a pure scroll the moving subtree should ride the retained rigid-translation path (motion_context_animated / translated_content_offset on LayerNode), but the partial scene update path re-emits per frame. (Scope a lazy-list scroll to its subtree instead of rebuilding the whole scene #504 scopes the lazy-list case; cranscan's Library is a LazyColumn, so it is exercised by this scene.)
2. Render pass count (35/frame on the cranscan page, 30–39 on the demo). On a tile-based mobile GPU every pass is a full tile store+reload. Isolated glass layers each cost capture + blur chain + composite passes; the DirectChunkRunCoalescer exists for exactly this reason but glass pages defeat it.
3. Layer captures invalidated by translation (65 % miss, 1.78 MP/frame). Scrolling translates layers and misses their cached captures. For backdrop-sampling glass this needs an architectural answer (e.g. blur the static background once per change into a shared texture and let moving cards sample it) rather than per-card re-blur per frame.

Cause 2 is addressed by #521, and my earlier reading of it here was wrong.
The constraint is real — DirectChunkRunCoalescer must flush the absorbed
direct run before a chunk that composites from cache (render_paths.rs:4338-4361)
or painter's order breaks — but I concluded from it that the pass count could
not be attacked without first reducing the layer count. That assumed the flush
had to be unconditional. It does not. #521's
flush_pending_queues_for_backdrop_capture flushes only when a pending
composite's written region (dest_quad ∩ scissor) actually intersects the
capture's dependency rect, plus the pending-clear case, and pins the ordering
failure that narrowing could cause with a test where one glass depends on
another's composited output. Cause 2 is fixed on its own, not gated behind
cause 3.

The layers have been attributed, and it rules out the caching fix. Per-layer
gpu_stats output over five scrolled frames splits them into 4 fixed chrome
layers (top bar, search field, a 139x126 element, one 44x44) and 1-4 transient
per-row 44x44 layers. By area the fixed chrome is 89 % of the isolated-layer
total — and the fixed layers are the ones whose backdrop is the scrolling
list, so their capture_rect is constant over genuinely different pixels every
frame. They cannot be cached by any strategy. The cacheable moving-glass
case is the remaining ~10 %.

So the critical path is making each per-frame blur cheaper — downsample
before blurring, fewer taps, smaller capture region, or reusing the previous
frame's blur under a small scroll delta — not a shared background texture.
Shared-background-blur remains correct for moving glass and is worth having,
but it is a tenth of this page. Cause 1 (#504) is real, separate, and gates
neither.

#521 attacks exactly this (cheaper per-pixel glass plus the pass batching
above). Unlike #497, it should move fps: it targets present 13.5 ms and
render 8.1 ms directly, against the ~3.4 ms this page needs to shed. That
makes it worth measuring on device rather than assuming — in both
directions. Method that this issue's own history argues for: same package,
app settled at 0-3 % CPU, judge only idle_iters≈0 windows, and carry an
untouched stage as a within-run control against CPU clock drift.

Two traps recorded in the comments before anyone starts: the cache key's
local_bounds_bits field is fed a screen-space rect for backdrop effects, so
making the key translation-invariant ships a stale backdrop; and the per-layer
diagnostic needed to redo this attribution already exists in gpu_stats
(gpu_stats.rs:333) — it does not need building.

Targets (same device, same scenes)

• scene_ms ≈ 0 during pure scroll (rigid translation, no re-emit)
• passes in the single digits per frame
• layer-cache scroll hit rate ≈ 100 % on the cranscan-style page
• both scenes at 60 fps with headroom

Notes

• This is the "retained translated/offscreen surface reuse for moving scroll content" / surface-planner work already flagged in TIME_WASTERS.md and docs/render_arch.md — now with concrete on-device numbers.
• Measurement traps. Wait for the app's own CPU to settle and print what it settled at before trusting any frame number; an app doing background inference, indexing, or sync will be measured as framework cost. Never A/B across two packages — install both arms over the same package, or flip arms inside one binary with a runtime override. Judge only idle_iters≈0 windows, and use single long input swipe drags. SurfaceFlinger shows steady 60 fps presents even while content is janky.
• Related but separate observations from the same session: app-startup windows show 1.9–5.5 s stalls, and acquire p90 spikes to 7–9 ms on some windows.

🤖 Generated with Claude Code

[samoylenkodmitry]

Mechanisms confirmed (traced + reproduced in tests)

All three ranked causes now have an exact mechanism rather than a symptom.

1. Scene re-emission — fixed in fix/scroll-renderer-surfaces

A scrolling LazyColumn was rebuilding the render graph from the composition root every frame. Two independent gaps stacked:

• The list invalidates through schedule_measure_repass (its item sizes change, so placement-only dirtiness is insufficient) — but run_layout_phase_in_context only ever collected node ids from layout repasses (shell_frame.rs). The measure ids were dropped, so the scene phase saw scene_dirty = true with an empty dirty set, read that as "everything changed", and took rebuild_scene_from_applier.
• Closing that alone was not enough: the layout phase runs twice per frame (initial, then after post-layout recomposition) and it assigned rather than accumulated the scoped ids. A second pass with nothing pending wiped what the first recorded, so scoping survived or vanished depending on which pass the scroll landed in.

The stale doc on LazyListState::dispatch_scroll_delta claimed schedule_layout_repass / "O(subtree) instead of O(entire app)" — the code had drifted from it, and the comment is now corrected.

Why no test caught it: lazy_column_scroll_repass_uses_scoped_renderer_update_without_stale_rows asserts updates + rebuilds == 1, accepting either path, while the sibling graphics_layer repass tests assert rebuilds == 0. New test lazy_column_scroll_never_rebuilds_the_whole_scene asserts zero rebuilds and one scoped update carrying dirty ids, across three steady-state scroll steps.

2. Render-pass count — mechanism identified

passes=39 against draws=31: most passes are single- or zero-draw infrastructure. render_range_with_layer_events_to_view walks layer events strictly sequentially with no lookahead or grouping, so each glass card costs its own capture + blur (2-pass separable ping-pong) + composite. Batching machinery does exist (encode_composite_batch_to_view_pass, encode_shader_batch_src_over_to_view).

Notable asymmetry worth a look: the regular composite queue is flushed only on a real dependency (pending_layer_composites_intersect_rect against the capture rect), but three lines later flush_pending_shader_layer_composites is called unconditionally at every backdrop boundary — the shader-composite batch is torn down for every card regardless of overlap.

Also: "Layer Event Clear Pass" burns an entire zero-draw pass whenever a layer event is first to touch a target, purely because the backdrop-apply helpers hardcode LoadOp::Load and cannot accept a caller-supplied load op. And blur downsample is chosen from radius alone — no tile-GPU awareness anywhere in the crate (no is_tile_based equivalent exists).

3. Backdrop cache thrash — mechanism identified

The asymmetry is the bug. An ordinary isolated layer has its capture re-based into a local (0,0) frame before keying, so pure translation leaves the key unchanged (hence 100% hits on light pages). A backdrop layer instead keys on its absolute on-screen capture_rect (LayerRasterCacheKey::backdrop_effect), so every scrolled frame is a new key → miss → full re-capture and re-run of the lensing shader.

layer_surface_cache.rs documents the phenomenon but engineers only around its secondary cost (texture-pool churn), not the re-blur.

Prior art to build on rather than duplicate: commit b028b6b7 ("A row over one flat colour keeps its raster while it scrolls") already made this translation-stable for the flat-colour case by putting the colour in the key. Widening that road looks more promising than a fresh shared-backdrop design, since its preconditions ("no gradient, no other draw reaching into the rect, no layer event, no sibling already composited there") are what a real card list fails.

---

Note for anyone measuring: the demo Liquid tab is CPU-bound (cpu p50 25 ms vs present 7.5 ms) so cause 1 dominates there, while cranscan's Library is GPU-bound (present p50 29-33 ms) so causes 2/3 dominate. Fixing one does not move the other.

[samoylenkodmitry]

Cause 3 traced to the code, and why the obvious fix is the wrong one

The 34.6 % layer-cache hit rate has a single mechanism, and it is worth writing down before anyone "fixes" it the fast way.

LayerRasterCacheKey has a field named local_bounds_bits (crates/cranpose-render/common/src/raster_cache.rs:61), which reads as translation-invariant. It is not, for backdrop effects. The call site passes a screen-space rect into that slot:

• crates/cranpose-render/wgpu/src/surface_executor/render_paths.rs:5599-5605 calls backdrop_effect_cache_key(layer, hash, capture_rect, ...)
• render_paths.rs:3032-3047 forwards that capture_rect into LayerRasterCacheKey::backdrop_effect(.., visible_rect, ..)
• raster_cache.rs:114-131 stores it as local_bounds_bits

So every scrolled frame moves capture_rect.y, changes the key, and misses. That is the 1.78 MP of blurred offscreen content re-rendered per frame.

The tempting fix — make the key translation-invariant — is incorrect. A backdrop effect caches the blurred content behind the card. When the card moves, the region behind it is genuinely different pixels, so a translation-invariant key would serve a stale backdrop and the glass would show the wrong background. The current key is right about what it identifies; the problem is the granularity of what is being cached.

The architectural answer is the one already in the issue body, and this confirms rather than replaces it: blur the background once per background change into a single shared texture, and let each glass card sample that texture at its own translated UV offset instead of owning a private blur keyed on its own screen position. Per-card blur cost then stops scaling with scroll position, and with 9 isolated layers and 7 live blurs on this page that is where the pass count goes too.

Supporting evidence that this is viable: input_content_hash is already threaded through the key as the identity of the captured content. For a scrolling list over a static background, that hash is stable while only capture_rect varies — which is precisely the signal a shared-background blur needs to know its cached texture is still valid.

Still to be designed (not claimed here): how the shared blurred background is invalidated when the background itself scrolls or animates, and how cards near the edge sample outside the captured region. Those are the real questions, and they are not answered by anything above.

🤖 Generated with Claude Code

[samoylenkodmitry]

Cause 2 traced: the coalescer is not broken, and causes 2 and 3 are one fix

Following the pass count into the code, DirectChunkRunCoalescer (render_paths.rs:113-131) absorbs consecutive direct chunks and flushes once. It is working as designed. What breaks the run is structural:

render_paths.rs:4338-4361 — when a chunk composites from the cache, the absorbed direct run must be flushed first to preserve painter's order, since the run sits below the composite in z. Every isolated layer interleaved in z with direct content therefore forces a pass boundary.

So pass count scales with isolated-layer count, and on the measured cranscan Library frame that is exactly what we see:

isolated_layers=9 | blur=7 | composite=12 | effect=10 | passes=35

The direct content is cut into ~10 runs by the 9 interleaved composites, plus each layer's own capture + blur-chain + composite passes. Nothing here is a coalescing bug — the coalescer cannot merge across a composite without reordering the frame.

This means cause 2 is not separately addressable, and should not be worked separately. There is no pass-batching change that keeps painter's order while 9 independent glass layers each own a private blur keyed on its own screen position. The pass count is a consequence of the isolated-layer count, and the isolated-layer count is a consequence of per-card backdrop blur — cause 3.

The shared-background-blur direction therefore pays twice: it collapses N per-card blurs into one background blur (cause 3, the 34.6 % hit rate and 1.78 MP/frame), and by removing N isolated layers it removes the N flush boundaries that fragment the direct run (cause 2, the 35 passes). Sizing the work as two independent items would overstate it and would likely produce a pass-batching attempt that cannot succeed.

Ranked-cause list should be read as: cause 3 is the work; cause 2 is its payoff; cause 1 (#504) is real but separate and does not gate either.

Relevant for anyone picking this up: layer_requires_isolation (crates/cranpose-render/common/src/layer_composition.rs:10) isolates unconditionally for CompositingStrategy::Offscreen, and under Auto on effect, blend mode other than SrcOver, or alpha < 1 — not on shape clip. So the 9 isolated layers on this page are genuinely the glass effects, not clipping artifacts, and reducing them means changing how glass is rendered rather than tuning an isolation heuristic.

🤖 Generated with Claude Code

[samoylenkodmitry]

Qualifying the cause-3 fix: it only works for glass that moves over a static background

My earlier comment traced the backdrop cache miss to capture_rect and proposed a shared background blur. Before anyone builds that, one distinction decides whether it can work at all, and I had glossed it.

Per-frame stats from two scrolled frames on the shipping Library page:

frame	isolated_layers	blur	cache hit	cache miss
f#180	5	3	5	9
f#240	9	7	9	17

Two things worth reading off this:

• Hits equal isolated_layers exactly, in both frames, with about twice that many misses. That is consistent with each glass layer's source content caching correctly (content-keyed, translation-invariant) while its backdrop effect misses. The source-content cache is working; the backdrop cache is the one at ~0 %.
• The counts vary between frames (5→9, blur 3→7). Fixed chrome would hold a constant count, so the glass count is tracking what is on screen.

The distinction that matters

There are two glass topologies here and they need opposite answers:

1. Glass that moves over a static background (a card with a blurred backdrop scrolling past a fixed page background). The backdrop content is unchanged; only the sampled window translates. This is cacheable, and the shared-background-blur direction is right — blur the background once, let cards sample it at an offset.
2. Fixed glass over scrolling content (a search field, top bar, or bottom bar whose backdrop is the moving list). Here capture_rect is constant and the content behind it genuinely changes every frame. No caching strategy can work. The blur must be recomputed per frame, and the only wins available are making it cheaper: downsample before blurring, fewer taps, smaller capture region, or reusing the previous frame's blur where the scroll delta is small enough to tolerate.

cranscan's Library has at least one of topology 2 — LiquidSearchField(.., on_glass: true) at app/src/ui/library.rs:686.

So the fix is not one change. Sizing this as "blur the background once and sample it" would fix topology 1 and silently do nothing for topology 2, and the measured page has both. Before implementing, the 9 isolated layers on this page need attributing to the two topologies — that count is the thing to measure next, and I have not done it.

This does not change the diagnosis (34.6 % hit rate, 1.78 MP re-blurred per frame, pass count following isolated-layer count). It changes what a fix has to cover.

🤖 Generated with Claude Code

[samoylenkodmitry]

Small follow-up on the attribution question I left open above: the existing gpu_stats counters cannot answer it, so don't spend time trying.

isolated_layers across the captured scrolled frames runs 5, 6, 7, 8, 9. That is equally consistent with "fixed chrome contributes a constant, cards contribute the variable part" and with "all of it is cards entering and leaving", and the aggregate counter carries no layer identity to separate them. The same applies to blur (3–7).

Attributing the isolated layers to the two topologies needs a per-layer diagnostic — layer id plus whether its capture_rect moved between frames — not more sampling of the existing counters. Whoever picks this up should budget for adding that diagnostic first; it is the measurement that decides whether the shared-background approach applies to most of the page or to a small part of it.

🤖 Generated with Claude Code

[samoylenkodmitry]

Correction: the diagnostic already exists, and the answer inverts the fix priority

Two comments up I said attributing the isolated layers needed "a per-layer diagnostic that does not exist yet". That was wrong — it already exists, and I had the data in my own captures and filtered it out by grepping for GPU f#.

gpu_stats prints one line per isolated layer (gpu_stats.rs:333):

[isolated #0] node=Some(10) rect=(0.0,0.0,360.0,65.7) target=... reasons=...

A node present in every sampled frame is fixed chrome; a node that comes and goes as the list scrolls is per-row glass. That is the split, and it needs no new instrumentation.

The attribution

Five sampled scrolled frames of the shipping Library page, 5–8 isolated layers each:

Fixed (present in all 5 frames)

node=10    360 x 65.7
node=14    344 x 64
node=18    139 x 126
node=181    44 x 44

Transient (come and go with the scroll) — 8 distinct nodes across the sample, all 44x44 except one 47x35, with 1–4 present per frame: 149, 203, 225, 247, 258, 330, 334, 338.

4 fixed + 1–4 transient = 5–8 per frame, which is exactly the observed range.

Why this inverts the priority

By area, the fixed layers are almost the entire cost:

	logical px²	share
fixed chrome (4 nodes)	65,118	89.4 %
the 3 large chrome layers alone	63,182	86.7 %
transient per-row glass (max 4 × 44²)	7,744	10.6 %

Corroboration that this reading is right: 72,862 logical px² at scale 3 is 0.66 MP, and the telemetry independently reports area=0.67MP on that frame.

The transient 44x44 layers are the ones that move over their own backdrop, so they are the cacheable topology — and they are ~10 % of the area. The layers that dominate are the top bar, the search field and the 139x126 element, all fixed glass over scrolling content: constant capture_rect, genuinely different pixels every frame, uncacheable by any strategy.

So shared-background-blur — the direction in this issue's body and in my own earlier comment — would address roughly a tenth of the isolated-layer area. It is not wrong, but it is not the fix for this page. The ~90 % is a blur that must be recomputed per frame, where the only available wins are making each one cheaper: downsample before blurring, fewer taps, a smaller capture region, or reusing the previous frame's blur when the scroll delta is small enough to tolerate.

That also re-reads cause 2. Pass count follows isolated-layer count, and the fixed chrome contributes 4 of 5–8 layers every frame regardless of scroll position, so pass count cannot be brought down by fixing the moving-glass case either.

Caveat I am not hiding

Five frames is a small sample, and node=181 (44x44) is classified fixed on that basis alone — a row that happened to stay on screen throughout would look identical. The three large chrome layers are unambiguous (they are the page furniture and carry 86.7 % of the area on their own), so the conclusion does not depend on 181 either way.

🤖 Generated with Claude Code

[samoylenkodmitry]

Cheaper per-frame blur implemented (branch worktree-huawei-scroll-perf); the next bottleneck is pass structure, measured and traced

What changed (same device, same protocol as above: EVR-AL00, quiet at 0 % settled CPU, single 2.5 s drags, debug.cranpose.frame_telemetry=1)

New framework-local scene for this topology: the demo's Glass Feed tab
(apps/desktop-demo/src/app/glass_feed.rs) — fixed glass top bar + search
field + filter panel over a scrolling LazyColumn of vivid gradient cards, a
44x44 glass button on every third row. Profile matches cranscan's Library
(passes 30-34, ~1.15 MP re-blurred per scrolled frame, layer cache at 50 %).

Three per-pixel cuts, all in the blur/glass shaders and material routing:

1. blur_fs.wgsl / blur_rounded_mask_fs.wgsl ran a fixed 65-iteration
   loop regardless of radius (for i in -32..=32 with a continue skip) —
   a radius-5.5 blur paid 65 iterations for 13 taps, per pixel, per axis, and
   the vertical pass runs at full capture resolution. The trip count now
   comes off the uniform (-tap_count..=tap_count), and sampling is
   explicit-LOD (textureSampleLevel) since every source is a mipless
   offscreen.
2. liquid_glass.wgsl sampled a 9x9 = 81-tap grid for the wcKSRD optical
   blur even though the material caps that blur at 2 px. Non-loupe glass now
   uses a 5x5 grid at half-radius spacing (every tap within bilinear reach of
   its neighbour — no grid quantization possible at the capped radius); the
   loupe rim keeps the 9x9 (its per-pixel softening reaches ~4.5 px).
3. Regular glass ran BOTH blurs on every pixel of every frame: the
   separable Gaussian (8 dp x density 3 = 24 px) plus the capped 2 px
   in-shader tap on top. A blur past the optical cap now rides the Gaussian
   pass entirely (sigmas add in quadrature: 24 px vs 22+2 px split differs by
   well under a percent), so the optical pass takes the single-tap path
   during steady scroll. Pinned by heavy_backdrop_blur_rides_the_gaussian_pass_alone
   and featherweight_backdrop_blur_stays_in_the_optical_tap in
   cranpose-liquid/src/material.rs.

Result on Glass Feed (scroll windows, idle_iters ≤ 30):

	before	after
fps	20.0	26.0
period p50	42.1 ms	34.6 ms
present p50	19.1 ms	12.5 ms (−35 %)
render (CPU encode) p50	14.9 ms	14.8 ms (unchanged, expected)
update p50	3.3 ms	3.1 ms

GPU counters unchanged (passes 29-34, blur 6-7, ~1.1 MP missed) — only the
per-pixel cost moved, as intended.

The remaining bottleneck, isolated by a control arm

Same build, same page, chrome removed (list + per-row glass buttons only):

	with fixed chrome	without
fps	26.0	48.0
render p50	14.8 ms	6.8 ms
present p50	12.5 ms	2.5 ms
passes/frame	29-34	10

Four fixed glass elements cost ~24 render passes, ~8 ms CPU encode and
~10 ms GPU per frame — ~2 ms CPU per glass element for what is nominally
3 passes and a copy. The blur math is no longer the cost; the pass
structure is, on both sides of the fence:

• Every backdrop capture (copy_texture_region_to_target reading the root
  target mid-frame) forces the tile pipeline to store and later reload the
  full ~2.4 MP root target. Four fixed glasses = four store/reload cycles.
• Each glass's optical output composites to the root target immediately
  inside apply_backdrop_layer_to_target (render_paths.rs:5849-5890) —
  never through the existing shader-composite batch.
• Before each capture the walk flushes both pending queues
  unconditionally (render_paths.rs:2316-2332 and the layer-source walk
  twins) — exactly the asymmetry called out earlier in this thread — so
  pending content composites land in their own passes even when they don't
  intersect the capture rect at all.

Concrete next step (cause 2, now with a bounded design)

Both queues and the batch encoder already exist
(PendingShaderLayerComposite, shader_composite_batch_to_view,
encode_composite_batch_to_view_pass). The change:

1. Make the pre-capture flushes dependency-checked: flush only when a
   pending composite's output intersects the capture rect (the regular
   queue already does this in the chunk path via
   pending_layer_composites_intersect_rect; the shader queue and the
   backdrop boundary never got the check).
2. Defer the uncached backdrop's final composite: encode capture + blur
   into an effect target as today, but push the optical/composite into the
   appropriate pending queue (shader tail → shader batch, plain effect →
   regular batch) instead of compositing immediately.

For N disjoint fixed glasses the encoder stream then becomes: content pass →
N copies (root target stays resolved — one store/reload cycle) → N small
blur chains → one batched optical pass. On this page that is ~24 passes
→ ~10, and it needs no reduction in isolated-layer count and no caching —
it works for the uncacheable fixed-glass topology because it batches
within the frame, orthogonal to caching across frames.

Deterministic regression shape (pinned before implementing): passes(N=3
fixed glasses) − passes(N=1) must equal the two per-glass blur passes, not
3x(blur+composite+flush); plus an overlap case proving a capture that
genuinely depends on an earlier glass's output still flushes first.

Measurement note for whoever re-runs this: the star buttons (glass moving
with its own backdrop — the cacheable topology) still miss 50 % of
lookups (0.22 MP/frame on the control arm) — that is cause 3's screen-space
capture_rect key, unchanged by any of the above.

[samoylenkodmitry]

The unconditional pre-capture flushes are gone; the flushes that remain on this page are real dependencies

Follow-up to the comment above; branch worktree-huawei-scroll-perf, second commit.

What changed

Both walks now flush the pending composite queues before a backdrop
snapshot copy only when a pending composite actually writes inside the
capture's dependency rect (padded capture ∪ output reach), or when a queue
still owns the frame's clear. The intersection test is scissor-aware — a
prepared backdrop composite's quad spans its whole padded capture and only
the scissor confines the write, so stacked glass elements otherwise read
as overlapping when their painted pixels never touch.

Two pinned regressions in cranpose-render-wgpu/tests/backdrop_pass_batching.rs:

• each_extra_fixed_glass_adds_only_its_blur_chain: on a three-glass
  fixed-chrome scroll scene, a scrolled frame went 15 → 13 passes; each
  extra disjoint glass now adds exactly its own small-target work (blur
  pair + cacheable materialize) and every composite rides the shared
  batch. Before the change each glass also fragmented the composites into
  its own root-target pass.
• an_overlapping_capture_still_sees_the_glass_below_it: a capture that
  genuinely depends on an earlier glass's output still flushes first.

Device numbers (Glass Feed, same protocol)

	round 1	round 2
passes/frame	34	29-30
present p50	12.2-12.9 ms	11.2-11.3 ms
fps	24.4-26.0	24.8-26.5
render (CPU encode) p50	~14.8 ms	~14.9 ms

Cumulative from the pre-session baseline: fps 20 → 26, present p50
19.1 → 11.3 ms, and the frame is pixel-identical at rest (full-frame
compare against the baseline build: zero pixels differ beyond a 30/765
threshold).

Why the improvement stops there on this page — measured, not guessed

The remaining per-element flushes on Glass Feed are semantically
required. Every chrome element carries the Regular-glass drop shadow
(radius 22 dp, spread 8), whose ring reaches ~28 dp beyond the element —
across the 10 dp gap and well into the next element's padded capture. The
next glass down genuinely blurs the previous element's shadow, so the
sequential order capture→composite→capture is a real data dependency, not
a batching failure.

That leaves this page render-CPU bound: encode p50 ~14.9 ms for 29 passes
against 6.8 ms/10 passes on the chrome-less control. Ranked follow-ups,
none started:

1. Defer shadow composites into the pending batch (split
   encode_shadow_draw into offscreen prep + a batch item). Halves the
   per-element root-target passes (flush + immediate shadow pass → one
   batch entry); the shadow-ring→next-capture dependency remains, but its
   cost drops to one combined pass per element.
2. Share the separable blur within same-radius groups (all Regular
   chrome is 24 px): one H+V over the union band instead of per-element
   pairs — needs a source-window remap for the optical pass.
3. Blur at scratch resolution end-to-end: the vertical pass still
   writes the full-res intermediate; keeping the chain at scratch res and
   letting the materialize pass upsample cuts the V-pass pixel count 16x.
   Uniform-space audit done (everything px-denominated derives from
   effect_rect/textureDimensions and scales together; uniform 93 is 0
   for chained glass since the routing change).
4. The retained translated-surface work from this issue's title is still
   the ceiling-raiser for the no-chrome baseline itself (48 fps, render
   p50 6.8 ms for a plain list scroll).

🤖 Generated with Claude Code

[samoylenkodmitry]

Correction: cause 2 is fixable on its own, and #521 fixes it

I wrote above that cause 2 was "not separately addressable" and should not be worked separately, because DirectChunkRunCoalescer must flush the absorbed direct run before any chunk that composites from cache or painter's order breaks.

The constraint was right. The conclusion was wrong, and #521 demonstrates it. I assumed the flush had to be unconditional, so every interleaved glass layer necessarily forced a pass boundary. It does not have to be.

flush_pending_queues_for_backdrop_capture flushes only when a pending composite's actually-written region — dest_quad intersected with its scissor, not the quad alone — overlaps the capture's dependency rect, plus the case where a pending load op holds a Clear (which covers every pixel and so always forces the flush). Captures that read nothing a pending composite wrote now ride the shared batch.

That is a correct narrowing rather than a relaxation, and it is pinned rather than assumed: backdrop_pass_batching.rs includes the case where a second glass depends on the first's composited output and asserts the lower glass stays visible — the exact failure this change could plausibly introduce.

The body is updated. Cause 2 should be read as fixed by #521, not as a consequence waiting on cause 3.

Worth stating why the wrong conclusion was still useful: the constraint was written down precisely enough — name the function, name the line range, name the ordering property — that someone could check it and find the gap. A vaguer note would have been unfalsifiable and would still be sitting here.

🤖 Generated with Claude Code