Finish the paint-cache migration to quadraui Rect/*Layout — the raw-tuple hold-outs are why the mouse appliers diverge

[JDonaghy]

The finding this replaces

The 2026-09-04 audit sized ~8,000 production lines across vimcode's two backends as "the same apply/marshalling logic written twice against different geometry types", and concluded it needed a new unit-neutral type upstream (filed as quadraui#781). Re-examining the actual fields shows that conclusion was wrong. The unit-neutral type already exists, is already adopted for most surfaces, and both backends already share a router over it. What remains is an unfinished migration.

The evidence

quadraui::Rect is f32-based (quadraui/src/event.rs:153-158) and every hit_test in the crate takes (x: f32, y: f32) — there is no unit parameter anywhere in quadraui's layout API. A TUI passes cell coordinates as f32; GTK passes pixels as f32; the same code runs.

Where vimcode already adopted it, the two backends are identical:

Cache field	App (GTK)	TuiShellApp
dialog_layout	quadraui::DialogLayout	quadraui::DialogLayout
completion_layout	quadraui::CompletionsLayout	quadraui::CompletionsLayout
context_menu_layout	quadraui::ContextMenuLayout	quadraui::ContextMenuLayout

Both clear them the same way each frame, and both feed them into the same shared router — GTK builds the struct at src/app.rs:3506, the TUI builds it at src/tui_main/mouse.rs:439. That is the pattern working today, at scale.

The divergence is confined to the fields that were never migrated:

Cache field	App (GTK)	TuiShellApp
tab_switcher_popup_rect	Option<(f64,f64,f64,f64)> — app.rs:503	Option<quadraui::Rect> — shell_app.rs:448
editor_hover_popup_rect	Option<(f64,f64,f64,f64)> — app.rs:492	Option<(u16,u16,u16,u16)> — shell_app.rs:438
panel_hover_popup_rect / hover_popup_rect	Option<(f64,f64,f64,f64)> — app.rs:489	Option<(u16,u16,u16,u16)> — shell_app.rs:437
picker_popup_rect	Option<(f64,f64,f64,f64)> — app.rs:544	—
panel_hover_link_rects	Vec<(f64,f64,f64,f64,String,bool)> — app.rs:486	HoverLinkRects — shell_app.rs:436
editor_hover_link_rects	Vec<(f64,f64,f64,f64,String)> — app.rs:569	HoverLinkRects — shell_app.rs:439

tab_switcher_popup_rect is the proof: the TUI already migrated it to quadraui::Rect and GTK did not. The direction works; it was half-finished.

The primitives for the hold-outs already exist and are unused:

• RichTextPopupLayout — hit_test(x, y) at primitives/rich_text_popup.rs:262, plus char_at(x, y, col_width) at :305
• TooltipLayout — hit_test(x, y, id) at primitives/tooltip.rs:261

vimcode hand-rolls both, in two incompatible tuple shapes, against primitives that ship hit-testing.

Why the appliers diverge

They diverge because the caches diverge. A (f64,f64,f64,f64) on one side and a (u16,u16,u16,u16) on the other cannot share a hit-test, so each backend writes its own — and once each has its own, the surrounding apply logic follows. Where the cache is a shared *Layout, the router is shared and the apply is one call.

Fix

1. Migrate every raw-tuple paint cache above to quadraui::Rect, or to the primitive's own *Layout where one exists (RichTextPopupLayout for the two hover popups and both link-rect vectors; TooltipLayout for tab tooltips).
2. Finish tab_switcher_popup_rect on the GTK side to match the TUI's already-migrated field.
3. Delete the per-backend hit-test arithmetic these fields exist to feed, and route through the primitive's hit_test / char_at.
4. Per feedback_cache_paint_layout: cache what paint returned; never re-derive geometry in a click handler.

Then re-measure, before assuming more work exists

The 8,000-line figure was a residual estimate — what was left after the other buckets were accounted for — not a census. Re-run the duplication measurement after this lands. The honest expectation is that a substantial part of it collapses once the caches agree, and whatever remains will be specific and nameable (most likely "primitive X returns a layout with no hit_test"), which is a small upstream issue rather than an architecture.

Do not size this work from the 8,000 figure, and do not promise a reduction from it in the PR.

Acceptance

• No raw (f64,f64,f64,f64) or (u16,u16,u16,u16) paint-cache field remains in either App or TuiShellApp.
• Black-box tests, both backends: hover popup click and link activation, tab tooltip, tab-switcher popup dismissal, picker popup outside-click.
• Assert on rendered output, not on a cache field being Some — ScreenLayout.picker was populated on GTK for months while nothing painted it (Command palette fails to open silently (broken on develop) #587), and GTK live render path silently drops 13 populated ScreenLayout fields (rest of #587's blast radius) #592 found 13 more fields in the same state.
• State in the PR that the new tests fail against unfixed develop.
• Report the re-measured duplication figure in the PR.

[JDonaghy]

Before you start: re-verify the citations, do not trust them

Every file:line in this issue was measured on develop @ ee26268 (2026-09-04) by an audit, not by reading the tree you will check out.

They will have drifted by the time you pick this up. This issue sits in a serialised chain, and several entries ahead of it move code on purpose — #812 deletes ~1,300 lines from src/render.rs, #813 retypes fields in src/app.rs, #785 and #814 delete whole functions. Anything filed after those shifts.

So:

• Locate by symbol, not by line. grep -n "fn build_screen_layout_with_breadcrumb_row" src/render.rs, not "go to line 12886". GOALS.md already carries this rule for the same reason — it cites no line numbers on purpose.
• Re-measure any count before you use it. Line totals here came from python3 scripts/prod_lines.py and scripts/native_lines.py at a named revision. Re-run them rather than quoting the number in this issue. GOALS.md: "regenerate them with the script rather than trusting the table."
• Size the branch from what you find, not from the figure here. The counts are evidence that a problem is large, not estimates of a diff.

If a finding does not reproduce, say so — that is a useful result

This issue was generated from an automated audit. Some of its claims are wrong. Today alone, two confident findings in the same audit chain did not survive checking: a "1,671 byte-identical lines" figure measured out at ~85, and a "zero commits of pin lag" reading was taken against a stale local ref and was actually 42.

If the problem described here is already fixed, was never real, or is real but different from the description: comment with what you actually found and stop. Do not implement around a bad premise to make the issue closeable. A correction is worth more than a merged PR built on a wrong claim.