animations demo: UI thread saturated idle (rAF text mutation defeats layer-tree reuse) + hover-transition present stalls

[codymullins]

Companion to #81. Traced 2026-06-10 on the live GUI showing the animations demo (http://localhost:8088/animations/, fixture testdata/sites/animations/). The page freezes during hover transitions; the trace shows the UI thread is already saturated before any interaction.

Findings

1. Layer-tree reuse never engages on this page. app.js auto-starts a WAAPI animation, and its rAF loop writes status.textContent every frame. The text mutation bumps LayoutInvalidationVersion, so WebviewPanel.LiveTick (src/Starling.Gui/Controls/WebviewPanel.cs:1591) takes the full relayout + rebuild path every tick and sets _animationTickPresent=false — the cached-tree fast path in NativeViewportRenderer.Present (src/Starling.Gui.Core/Rendering/NativeViewportRenderer.cs:126) is skipped on every frame. Idle trace: UI thread 100% busy, 7.3s of 8.5s inside LayerTreeBuilder.Build.

2. The rebuild cost is dominated by the per-box style-override callback. WebviewPanel.AnimatedStyle runs for every box during Build (via DisplayListBuilder.EffectiveStyle, 5.1s of the 8.5s idle trace), enumerating Animation/Transition ActiveProperties per box per frame.

3. Hover transitions stack ~170ms synchronous present stalls on top. A hover state change is a non-animation present (whole-tree rebuild by design), and the 2048x512 tiles containing the hovered element re-raster. Those tiles hold cards with box-shadow: 0 18px 40px: the shadow blur is cached (BoxShadowRasterCache) but every draw runs an ImageSharp CPU bicubic resize to device scale (CloningImageProcessor) — 4.7s in a 16s hover-toggle trace. Transition start/end also flips layer promotion (TransitionEngine.ActiveProperties -> IsElementAnimatingLayerRoot), re-keying the base slice and forcing extra base-tile re-rasters.

Work items

• Don't let a paint-only / single-layer text mutation force the full-rebuild path: scope the rebuild to the mutated layer (the recently-mutated promotion already isolates it) and keep _animationTickPresent for the rest of the tree.
• Cheapen or cache the per-box AnimatedStyle probe during Build (e.g. an animating-element set computed once per frame instead of two enumerator probes per box).
• Make hover presents reuse the cached tree, refreshing only the hover-affected layer.
• Stop the per-draw CPU resize of cached shadow rasters: cache at device scale or serve shadows from a GPU texture (overlaps the GPU filter pipeline in github.com beachballs ~30s on load: CPU Gaussian blur runs per tile on the UI thread (+ hydration, shutdown-abort follow-ups) #81).
• Damp promotion flip-flop at transition start/end (hysteresis like WasRecentlyMutated) so the base slice is not re-keyed twice per transition.

[codymullins]

All five work items landed (merged via worktree agent, commits ac81fdb0 + f8bed3ad):

• Box shadows rasterize and cache at device scale and blit 1:1 — no more per-draw bicubic resize.
• The per-box animation probe is now a per-frame set lookup (both engines grew CollectActiveElements, covering WAAPI script animations too).
• Transition-end demotion has a 3-frame hysteresis (FrameCountdownSet), folding the re-key into the next natural rebuild.
• Contained-mutation frames (the rAF textContent pattern) and hover toggles now reuse the cached layer tree and rebuild only the touched promoted layers. The invariant and its guards are documented at WebviewPanel.TrySnapshotScopedMutationRoots.

Measured after merge on the animations demo: process CPU ~200% → ~98%, and the full per-frame LayerTreeBuilder.Build is gone from the trace (the scoped RefreshAnimating path runs instead). github.com post-load CPU ~200% → ~44%.

Newly exposed bottleneck, next work item: with the rebuild waste gone, the demo's UI thread is still saturated — now 85% inside StyleEngine.ComputeWithAnimations, a full style recompute per animating element per frame (~1.5 ms each, 11 elements, every tick). The fix is incremental animated-style sampling: cache the element's base computed style and overlay only the animated properties per tick.

[codymullins]

The ComputeWithAnimations bottleneck is fixed (063525e2).

The real magnitude only showed up when counting ticks: the demo was running at ~0.25 frames per second — each live tick took ~4 seconds, almost all of it re-cascading every animating element AND its ancestors (no cascade cache on the per-tick path).

A pure animation tick cannot change the static cascade (any style-affecting mutation forces a relayout, whose box-tree build runs the full compose with a fresh static style). So the new AnimationCompositor.Sample overlays only the current animation/transition values, and the GUI feeds it the box's own style as the base. Trigger detection stays on the relayout path — running the full compose over a baked style would poison the transition snapshots with mid-tween values, which a new test pins.

Measured: 2 live ticks per 8.5s → 362 (~43 fps) on the animations demo. The remaining per-frame cost is honest work (JS pump + animating-layer tile rasters).

Closing the loop on all items in this issue.