He said the tooltip lag is not only signs, so the two hover benches now tally
layout derives and the live frame count per window, which is what turned the
sign case from a hypothesis into a number.
What they say. A held hover is clean: 1.7 ms/frame under forty plates, 0.76
in a city, and no per-frame derive. A rebuild costs 6.1 ms and gives up
naming the graph exactly once, always at frame_id — the mint of a frame the
model has not seen, which is the one write that genuinely cannot be named,
since a new node has to join the cached graph.
The frame is not ours. OctoPawn hooks GameTooltip's OnShow and creates an
anonymous frame on every show, purely to own a one-shot OnUpdate delay —
twice over, from ScoringCore.lua:540 and Pdmo.lua:101, which is the ordinary
1.12 way to write C_Timer.After. So every tooltip raise on his interface
mints frames and re-derives, on the reference client too. Live frames rise by
far less than the number created (137 against 480), so Lua reclaims most of
them: a cost per raise, not an unbounded leak.
Not acted on, deliberately. The lever would be letting a brand-new leaf join
the cached graph without a full derive, which is a layout-engine change and
wants its own measurement, not a change tacked onto a bug session.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SgstFWtn1RxEJ5kVrpgYwn
gromandClaude Opus 5
96e95a51ec