Minimap: VS Code-consistent width, stop rebuilding the whole buffer every frame, and stop overdrawing the status line

[JDonaghy]

Summary

Four minimap defects from one operator smoke against VS Code, all reproduced on develop @ e02a824, built from source (not a stale binary).

1. Width — about 120px, not 15% of the pane

MINIMAP_WIDTH_FRACTION = 0.15 with a 240px cap (src/render.rs:4362, 4397) makes the strip roughly twice VS Code's. VS Code derives its width from minimap.maxColumn (120) times 1px per column.

Spec: width = min(120 * scale, pane-fraction cap), keeping the MINIMAP_MIN_TEXT_COLS suppression and the per-pane keying from #722. This lines up exactly with quadraui's own colour-bar heuristic, which already assumes 120 columns (ASSUMED_WIDE_LINE_CHARS) — at 120px that is precisely 1px per column.

2. Performance — O(buffer) per frame, per pane

Wheel-scrolling a 10,000-line file is unusable until :set nominimap. build_minimap_data allocates a String for every line in the buffer, every frame:

// src/render.rs:4504
let owned: Vec<String> = (0..total_buffer_lines).map(|i| ...to_string()).collect();

then sample_lines clones again the ~400 it actually keeps. And there is no frame-to-frame reuse to fall back on: render_content writes cached_screen_layout at src/gtk/mod.rs:8404 on every draw and never reads it back across frames, so every wheel tick pays the full cost.

Fix: choose the sampled line indices first, then fetch only those lines from the rope — the stride is known before any text is needed. sample_lines takes &[&str], so this needs either a sibling entry point that takes an index-and-fetch closure or an index-only variant in quadraui; either is acceptable, but stop materialising the buffer.

Secondary, same function: to_col (src/render.rs:4548) does a chars().count() prefix scan per span, which is quadratic on a long line. Fix it while you are there.

Acceptance here is a measurement, not a claim. There is no bench harness in this repo (no benches/, no criterion). Add one, or a timed test, and report before/after frame cost for a 10,000-line file under sustained wheel scroll. A fix without a number is not done.

3. The strip overdraws the status line

build_screen_layout reserves a status row only when per_window_status && !separate_status (src/render.rs:6925), while h_scrollbar_geometry answers the very same question with a different predicate — engine.settings.window_status_line && !engine.terminal_maximized (src/gtk/mod.rs:10313). Two independent answers to "is a per-window status line painted here" is the defect; one of them is wrong in at least one configuration.

Reconcile them behind a single helper, and assert the strip's painted rect never intersects the status row across all combinations of window_status_line / status_line_above_terminal / bottom-panel-open / terminal_maximized.

4. Fixed row pitch, once quadraui lands it

Pass quadraui's MinimapSizing::FixedPitch (quadraui#667) and stop deriving target_lines from display_rows * MINIMAP_LINES_PER_ROW on GTK, so the row count follows the strip and the pitch rather than the file's length. Needs the pin bump — sequence this after quadraui#667.

Not in this issue

The missing scrollbar is #723, reopened: it still reproduces on its own fix.

Files

• src/render.rs — MINIMAP_WIDTH_FRACTION and caps, build_minimap_data, status-row reservation, to_col
• src/gtk/mod.rs — status-row predicate reconciliation
• src/quadraui_pin.rs — pin bump
• benches/ (new) or a timed test

Surfaced by

Operator smoke against VS Code, 2026-09-01.

[JDonaghy]

Coordinator Assignment

Machine: precision
Repo: vimcode
Files: (unspecified)
Do not touch: (nothing else in flight)

Briefing

Issue #728: Minimap: VS Code-consistent width, stop rebuilding the whole buffer every frame, and stop overdrawing the status line

Summary

Four minimap defects from one operator smoke against VS Code, all reproduced on develop @ e02a824, built from source (not a stale binary).

1. Width — about 120px, not 15% of the pane

MINIMAP_WIDTH_FRACTION = 0.15 with a 240px cap (src/render.rs:4362, 4397) makes the strip roughly twice VS Code's. VS Code derives its width from minimap.maxColumn (120) times 1px per column.

Spec: width = min(120 * scale, pane-fraction cap), keeping the MINIMAP_MIN_TEXT_COLS suppression and the per-pane keying from #722. This lines up exactly with quadraui's own colour-bar heuristic, which already assumes 120 columns (ASSUMED_WIDE_LINE_CHARS) — at 120px that is precisely 1px per column.

2. Performance — O(buffer) per frame, per pane

Wheel-scrolling a 10,000-line file is unusable until :set nominimap. build_minimap_data allocates a String for every line in the buffer, every frame:

// src/render.rs:4504
let owned: Vec<String> = (0..total_buffer_lines).map(|i| ...to_string()).collect();

then sample_lines clones again the ~400 it actually keeps. And there is no frame-to-frame reuse to fall back on: render_content writes cached_screen_layout at src/gtk/mod.rs:8404 on every draw and never reads it back across frames, so every wheel tick pays the full cost.

Fix: choose the sampled line indices first, then fetch only those lines from the rope — the stride is known before any text is needed. sample_lines takes &[&str], so this needs either a sibling entry point that takes an index-and-fetch closure or an index-only variant in quadraui; either is acceptable, but stop materialising the buffer.

Secondary, same function: to_col (src/render.rs:4548) does a chars().count() prefix scan per span, which is quadratic on a long line. Fix it while you are there.

Acceptance here is a measurement, not a claim. There is no bench harness in this repo (no benches/, no criterion). Add one, or a timed test, and report before/after frame cost for a 10,000-line file under sustained wheel scroll. A fix without a number is not done.

3. The strip overdraws the status line

build_screen_layout reserves a status row only when per_window_status && !separate_status (src/render.rs:6925), while h_scrollbar_geometry answers the very same question with a different predicate — engine.settings.window_status_line && !engine.terminal_maximized (src/gtk/mod.rs:10313). Two independent answers to "is a per-window status line painted here" is the defect; one of them is wrong in at least one configuration.

Reconcile them behind a single helper, and assert the strip's painted rect never intersects the status row across all combinations of window_status_line / status_line_above_terminal / bottom-panel-open / terminal_maximized.

4. Fixed row pitch, once quadraui lands it

Pass quadraui's MinimapSizing::FixedPitch (quadraui#667) and stop deriving target_lines from display_rows * MINIMAP_LINES_PER_ROW on GTK, so the row count follows the strip and the pitch rather than the file's length. Needs the pin bump — sequence this after quadraui#667.

Not in this issue

The missing scrollbar is #723, reopened: it still reproduces on its own fix.

Files

• src/render.rs — MINIMAP_WIDTH_FRACTION and caps, build_minimap_data, status-row reservation, to_col
• src/gtk/mod.rs — status-row predicate reconciliation
• src/quadraui_pin.rs — pin bump
• benches/ (new) or a timed test

Surfaced by

Operator smoke against VS Code, 2026-09-01.

[JDonaghy]

Coordinator: Assignment Complete

Machine: precision
Status: done
Exit code: 0
Duration: 30m 36s
Log: /home/john/.coord/logs/93b0c6cd38ab.log

[JDonaghy]

Coordinator: Assignment Complete

Machine: precision
Status: done
Exit code: 0
Duration: 30m 36s
Log: /home/john/.coord/logs/93b0c6cd38ab.log

[JDonaghy]

Coordinator Assignment

Machine: precision
Repo: vimcode
Files: (unspecified)
Do not touch: (nothing else in flight)

Briefing

You are fixing a failed smoke test for issue #728: Minimap: VS Code-consistent width, stop rebuilding the whole buffer every frame, and stop overdrawing the status line

The previous worker created branch issue-728-minimap-vs-code-consistent-width-stop-re. You are already on that branch.
Do NOT start over — work from the existing code.

What was done

The previous worker's changes are already committed on this branch.
Run git fetch origin && git log --oneline origin/develop..HEAD to see what was done.
Run git diff origin/develop...HEAD to see the full diff.

Test failure

cargo test: render::tests::minimap_scroll_does_not_scale_with_buffer_size fails perf budget (517-586ms vs 500ms) under full-suite contention, though passes in isolation (~416ms)

Guidance

Fix the failing tests and push.

Rules

• Do NOT start over or rewrite from scratch
• Fix the specific test failures
• Commit your fixes and push with git push origin HEAD

[JDonaghy]

Coordinator: Assignment Complete

Machine: precision
Status: done
Exit code: 0
Duration: 2m 46s
Log: /home/john/.coord/logs/1e004eb6ca0c.log

[JDonaghy]

Coordinator: Assignment Complete

Machine: precision
Status: done
Exit code: 0
Duration: 7m 38s
Log: /home/john/.coord/logs/9352e7157116.log

[JDonaghy]

Coordinator: Assignment Complete

Machine: precision
Status: done
Exit code: 0
Duration: 1m 51s
Log: /home/john/.coord/logs/96c8e233d3ab.log

[JDonaghy]

Coordinator: Assignment Complete

Machine: dellserver
Status: done
Exit code: 0
Duration: —

Summary

Verdict: approve

Review findings

Blocking findings

None.

Non-blocking concerns

• src/gtk/testing.rs — minimap_strip_never_overlaps_the_per_window_status_row doesn't actually exercise the divergence axis Minimap: VS Code-consistent width, stop rebuilding the whole buffer every frame, and stop overdrawing the status line #728 item 3 was about (separate_status/terminal_maximized). With window_status_line=true and no bottom panel/terminal-maximized, the old per_window_status && !separate_status predicate and the new window_status_row_reserved already agreed, so this specific test would also pass unmodified on pre-fix develop — it's a fine baseline sanity check but isn't the RED-discriminating black-box coverage for the actual bug. The genuine regression coverage for item 3 lives in src/gtk/mod.rs's h_scrollbar_status_offset_tests instead, which is explicitly RED-verified (13.0 vs 33.0, documented in the test comment) — so the PR's overall black-box bar is still met, this one test just isn't pulling the weight its docstring implies.
• src/render.rs — window_status_row_reserved_is_deterministic_across_all_combinations recomputes its expected value with a literal copy of window_status_row_reserved's own formula (window_status_line && !terminal_maximized && !(!status_line_above_terminal && bottom_panel_open)), so it mostly checks that the duplicate stayed in sync with the implementation rather than validating against independently-derived/rendered behavior. Low risk given the axis-by-axis test right above it (window_status_row_reserved_covers_every_axis) does assert real behavior with literal booleans, but worth knowing this one is largely tautological.
• Per CLAUDE.md's "state that the new black-box test was observed RED against unfixed develop" rule, only the status-row-divergence test (gtk/mod.rs) and the perf ratio test (2nd commit) carry an explicit RED/GREEN statement; the width-formula tests rely on inline arithmetic (e.g. 1600 * 0.15 = 240 vs the 150px/MINIMAP_TARGET_COLS threshold) that is clearly and verifiably RED pre-fix, but isn't phrased as an explicit "observed RED" claim. Not a real risk here since the math is trivially checkable, just short of the letter of the rule.

Nits

• None beyond the above.

Summary (for context)

Verified against the pinned quadraui rev (973956e) source: sample_lines's stride formula, MinimapLine.line_idx field visibility, and aggregate_spans's cell-column cutoff all match what minimap_sample_indices/MINIMAP_COL_SCAN_LIMIT assume — the index-first sampling and capped to_col scan are both semantically equivalent to the pre-fix (uncapped) behavior for every span that survives aggregate_spans's own column cutoff, and strictly cheaper otherwise. window_status_row_reserved is genuinely a single source of truth now (verified per_window_status/separate_status locals are still used elsewhere in build_screen_layout_with_breadcrumb_row, so no dead code), and both call sites (build_screen_layout_with_breadcrumb_row, GTK's h_scrollbar_geometry) were confirmed wired to it. Scope matches the issue exactly (render.rs width/perf/status-row, gtk/mod.rs predicate reconciliation); item 4 (quadraui#667 FixedPitch) is explicitly and correctly deferred with reasoning, no pin bump attempted. No CLAUDE.md/coordinator-doc changes. The previously-flagged flaky perf test (minimap_scroll_does_not_scale_with_buffer_size, 517-586ms vs 500ms under contention) is directly and thoroughly fixed by the second commit, converting it to a contention-proof interleaved ratio assertion with documented RED/GREEN verification (10.27x broken vs ~0.96x fixed, threshold 4.0x) plus a busy-loop contention check. No security concerns; no platform-neutrality violations (the shared predicate lives in render.rs, GTK only does thin wiring).