perf(desktop): stop the whole transcript re-rendering on sash drag

[OutThisLife]

Chasing the symptom Brooklyn reported: with a thread spinning, resizing the sidebar feels slow.

It reproduces

New idle-cost scenario holds N tiles busy, pushes no tokens, and measures the renderer's self-inflicted commit rate plus fps while dragging the splitter and while typing. Five busy tiles, nothing streaming:

idle commits   17.7/sec   <- nothing is happening
drag            1.4 fps   <- p95 812ms, worst frame 1.9s
typing           61 fps   <- fine; specific to resize

The real bug: every zone subscribed to the whole layout tree

TreeGroup called useStore($layoutTree) to build its right-click menu's move/split directions. That subscribes every zone — and therefore every mounted pane and its entire transcript — to the whole layout tree. A sash drag rewrites the tree once per frame, so dragging the sidebar re-rendered all five tiles' message lists on every pointermove, for a context menu nobody had open.

The directions are only read when the menu renders, so read the tree there with .get(). Same lazy shape the neighbouring closable prop already uses.

One 60px sash drag, five busy tiles:

	before	after
commits	83	12
ChatView	150 (4465ms)	10 (353ms)
AuiProvider	9,450 (9868ms)	630 (774ms)
TreeGroup	180	12
TreeSplit	90	6

Notably the atom churn list came back empty — this was never store churn, so render attribution was the only thing that could have found it.

Also: 107 eager tooltip providers

Tip mounted a full Radix provider + Tooltip per call site, and there are 107. Radix's Tooltip holds real state and Popper subscribes to layout, so unrelated interactions re-rendered all of them — 105,385 TooltipProvider renders in one gesture. Now mounted lazily on first hover/focus.

defaultOpen on the armed Tooltip is load-bearing: the pointerenter that armed it has already fired, so Radix never sees it and the tip mounts silently closed. A test caught exactly that and now guards it.

Harness fixes found along the way

• The drag wasn't dragging. It oscillated ±3px, netting zero displacement — reporting confident fps for a gesture that never moved the sash. Now sweeps monotonically and records dragMoved (60px, was 0).
• Observer effect. idle-cost recorded render attribution during the timed gesture, and the counter walks the fiber tree on every commit. That was large enough to hide this 15x render reduction behind an unchanged fps. Timing and attribution are separate passes now; record defaults off.
• Adds scripts/diag-drag-churn.mjs, the probe that found this. It reports the transcript chain (who above the messages re-rendered) plus every atom that notified.

Honest status on fps

Renders are down 15x but wall-clock drag fps is still ~3. With commits at 12, React is no longer the cost — the remaining time is layout/paint, which is a different fix and a different PR. I'm reporting the render win because it's measured and real, not claiming the interaction is fixed.

I also tried a flex-during-drag / commit-on-pointerup change to tree-split and reverted it: byte-identical numbers, so the sash handler was never the cause.

[github-actions]

૮ >ﻌ< ა ci review

_{ran on 0226d11}

ℹ️ Info

Desktop E2E visual evidence · View test artifacts · View job

1 visual diff.

_{inline evidence upload failed.}

Failed to upload diff-665a0833239e-onboarding-overlay-diff.png with gh image (exit code 1): Error uploading /home/runner/work/_temp/e2e-evidence/diff-665a0833239e-onboarding-overlay-diff.png: step 0 (get upload token): uploadToken not found on repo page — do you have write access to NousResearch/hermes-agent? (or, if NousResearch enforces SAML SSO, authorize at https://github.com/orgs/NousResearch/sso)

[OutThisLife]

Follow-up on the one loose end I flagged — Streamdown's 105 idle self-renders are not a bug, and I was wrong to call them one.

Doing the arithmetic instead of reading the raw count: the idle window is 6s at ~18.3 commits/s = ~110 commits. Streamdown renders 105 times. That is ~1.0 renders per commit, i.e. exactly one Streamdown instance updating per commit — the single open streaming message — not 105 instances thrashing. Same for MessageAge (105) and WaveSine (0.97/commit).

Per-commit, the idle picture is:

Streamdown     0.95/commit   <- correct: one open turn
WaveSine       0.97/commit   <- correct
Block          3.69/commit   <- ~4 blocks re-render per update
Tip            4.23/commit
Primitive.div  5.73/commit

So the remaining idle cost is not "Streamdown re-renders itself for no reason", it's that one message update re-renders ~4 blocks and their tooltip chrome. That's a narrower and more honest target than what I wrote in the commit message for the markdown-cache change.

The markdown cache commit still stands on its own merits (Block 128ms → 85ms, Ct 122ms → 81ms, stable array identity verified by test) — it just isn't the fix for a problem that turned out not to exist.

Net: the ~18 commits/sec idle rate is largely legitimate work for an open turn, driven by the per-second timers (GlyphSpinner 79, StreamStallIndicator 35, LiveDuration 7 across five tiles). The genuine waste in this PR is the layout-tree subscription, which is fixed.