`SetVerticalScroll` and `SetHorizontalScroll` called `Model::touch_layout` on
the line before `reanchor_child`. That gave up naming for the whole graph and
then *erased* the precise touch that followed: `reanchor_child` re-anchors the
scroll child through `write_anchor`, which reads an offsets-only change (same
point, same target) and names the child node — but `touch_layout_node` will not
un-say an imprecise touch, so the give-up won on every call.
Naming the child is the whole truth here. A scroll offset reaches the layout
only as that one anchor: anchor targets are ids fixed at `SetPoint`, so no edge
moves and the roster is unchanged, and the clip a scroll child draws within is
the ScrollFrame's resolved rect rather than the offset —
`clip::scroll_clip_sources` rebuilds it per call and caches nothing.
Measured on grom's 2026-10-21 17:08 session, which was a map-and-panel run.
These two lines were **472 of the run's 806 whole-graph derivations**, the
largest single source by a factor of two, and the cost lands on the Lua that
reads a frame edge afterwards rather than on the pass's own `resolve` phase:
| | n | fps | UI pass | `frame:GetLeft` |
|---|---|---|---|---|
| windows with >= 10 scroll derivations | 12 | 68.5 (min 53) | 5.93 ms/f | 2.18 ms/f |
| windows with no derivations at all | 11 | 92.4 (min 77) | 1.62 ms/f | 0.05 ms/f |
`r(scroll derivations, GetLeft us/f) = +0.907` over 57 in-play windows, against
`+0.014` for every other derivation site. `[ui-verbs]` has `frame:GetLeft` at
94-376 us a call in those windows and 0.6-1.5 us in the quiet ones, on ~14 calls
a frame, because stock FrameXML reads frame edges constantly and each read past
the clean epoch re-derived. That is why a scrolling panel — the world map, the
quest log, a profession list — was the expensive thing on screen.
The test scrolls both axes on the shipped interface and asserts zero
derivations, with a positive control so it cannot pass on a dead counter. Put
one `touch_layout` back and it reads exactly 10 for 10 scrolls.
`WOW_LAYOUT_VERIFY=1` over the real 92-addon interface gives
`frames 13379 -> 13379, regions 29597 -> 29645` — identical to the recorded
pre-existing baseline, so this narrowing introduced nothing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SgstFWtn1RxEJ5kVrpgYwn
gromandClaude Opus 5
e6ae2e0f67