Greptile Summary

This PR reduces scroll jank by coalescing viewport-read state updates behind a 16 ms timer (instead of a microtask), moving syntax-highlight jobs from microtasks to setTimeout(0) to yield to input/render callbacks, and scoping hover-clear signals to only the currently-hovered file to avoid cascading DiffSection re-renders.

• DiffPane.tsx: Adds hoveredFileIdRef to track hover ownership without stale-closure problems, replaces the queueMicrotask viewport coalescer with setTimeout(16) (with proper cleanup in the effect return), and gates hoverClearSignal on the specific addNoteHoverClearFileId so other DiffSections skip the re-render.
• pierre.ts: Single-line swap of queueMicrotask → setTimeout(0) in queueHighlightedWork to let UI timers interleave with background highlight jobs.
• benchmarks/large-stream.ts: Disables IS_REACT_ACT_ENVIRONMENT post-init to stop the test harness from draining timers, but this also prevents the new 16 ms viewport-read timer from firing in the scroll-tick loop, so windowed_scroll_ticks_ms now measures a narrower slice of the scroll path than before.

Confidence Score: 4/5

The production changes to DiffPane and pierre.ts are safe to ship — hover state management stays synchronized between ref and React state, and the effect cleanup correctly cancels any in-flight timer.

The core scroll coalescing and highlight-yielding changes are well-implemented with no logic gaps. The one concern is in the benchmark: disabling IS_REACT_ACT_ENVIRONMENT prevents the new 16 ms viewport-read timer from firing during the scroll-tick loop, so the windowed_scroll_ticks_ms metric no longer reflects the full production scroll path. The benchmark will show artificially fast numbers for the scroll path that was optimized, which could mask regressions in future PRs that benchmark against this baseline.

benchmarks/large-stream.ts — the scroll-tick measurement no longer exercises the viewport-read state update that was the primary target of this optimization.

Important Files Changed

Sequence Diagram

sequenceDiagram
    participant User
    participant OpenTUI
    participant handleViewportChange
    participant setTimeout16
    participant readViewport
    participant React

    User->>OpenTUI: scroll event (wheel / key repeat)
    OpenTUI->>handleViewportChange: "change" / "layout-changed"
    alt "scheduled = false"
        handleViewportChange->>setTimeout16: schedule(16ms)
        Note over handleViewportChange: scheduled = true
    else "scheduled = true"
        handleViewportChange-->>handleViewportChange: skip (coalesced)
    end
    Note over User,OpenTUI: more scroll events arrive within 16ms (all skipped)
    setTimeout16->>readViewport: fire after ~16ms
    readViewport->>React: setScrollViewport(top, height)
    readViewport->>React: clearAddNoteHoverForScroll (targeted file only)
    React-->>OpenTUI: re-render windowed DiffSections

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
benchmarks/large-stream.ts:91-107
**Scroll-tick metric may no longer exercise the coalesced viewport-read path**

With `IS_REACT_ACT_ENVIRONMENT = false` set before this loop, `await setup.renderOnce()` won't drain timers. The `handleViewportChange` handler schedules a `setTimeout(..., 16)` on each scroll event; since that timer is never advanced here, `readViewport()` / `setScrollViewport()` never fires during the measurement window. The loop is therefore timing scroll-event dispatch + a raw render with an unchanged React viewport state — it no longer measures the React-state-update cost that was the target of the coalescing optimization. The metric will report numbers that look good because the heaviest part of the optimized path isn't running.

_{Reviews (1): Last reviewed commit: "perf(ui): yield scroll updates and highl..." | Re-trigger Greptile}

Fixed in e991b25: the scroll benchmark now waits for VIEWPORT_READ_COALESCE_MS + 1 after each wheel event, so the timer-coalesced viewport read updates React state before renderOnce() is measured.

Fixed-harness results:

So with the viewport-read path included, the scroll metric still improves from 7220.48ms to 5802.51ms for 4 scroll ticks (~20% faster).

@fink-andreas Thanks for submitting. I made one tweak that removed a magic number (16) in favor of a declared const (maybe a bit inelegant having a dedicated file for this but hey, at least discoverable).