[BUG] Fullscreen: full-viewport repaints degrade whole-window latency in the VS Code integrated terminal (root-caused; scrolling not required)

Root cause found — editor.accessibilitySupport: "on" on my side, amplified by fullscreen's full-viewport repaint

Setting "editor.accessibilitySupport": "off" in VS Code eliminates the lag completely on my machine. I had it set to "on". Posting the full chain because the amplification is Claude Code's side, and because it invalidates one row of my "What I ruled out" table.

The chain

VS Code pipes that setting directly into xterm.js (resources/app/out/vs/workbench/workbench.desktop.main.js, 1.132.0):

updateAccessibilitySupport() {
  this.xterm.raw.options.screenReaderMode = this._accessibilityService.isScreenReaderOptimized()
}

screenReaderMode: true makes xterm construct AccessibilityManager, which mirrors the viewport into a parallel DOM tree — one <div> per terminal row. Its per-render refresh loop (xterm core, shipped in node_modules.asar) does this for every row, on every render:

a.textContent = o;
a.setAttribute("aria-posinset", n);
a.setAttribute("aria-setsize", s);
this._alignRowWidth(a);

and _alignRowWidth is the problem:

_alignRowWidth(e) {
  e.style.transform = "";                          // invalidates layout
  const t = e.getBoundingClientRect().width;       // forces synchronous layout
  const i = this._rowColumns.get(e)?.slice(-1)?.[0];
  if (!i) return;
  const s = i * this._renderService.dimensions.css.cell.width;
  e.style.transform = `scaleX(${s / t})`;          // invalidates again
}

Write → forced read → write, per row, per render. Classic layout thrash: one forced synchronous reflow per terminal row per frame.

There is a second cost on the parser side. In InputHandler.print(), the per-character hot loop:

if (screenReaderMode) { this._onA11yChar.fire(stringFromCodePoint(code)); }

An emitter dispatch plus a string allocation for every character printed, feeding a debounced ARIA live region.

Why this matches every symptom I reported

• Trace shows 17.2s of 20.1s in Commit with under 400ms of JS across xterm/webgl/workbench. Forced reflow is browser layout, not JS self-time. It lands almost entirely outside the JS attribution, which is why the numbers looked contradictory.
• gpuAcceleration: "off" changed nothing. In 1.132 _shouldLoadWebgl() reads only terminal.integrated.gpuAcceleration; screen reader mode is not gated on the renderer, and this cost is DOM layout regardless of which renderer draws. My table row claiming this eliminated a rendering-side cause was wrong — it never touched this path.
• VS Code's own UI (terminal split/close buttons) lags identically. Same renderer main thread, blocked by the same forced layouts.
• less --mouse over 20,000 dense-styled lines stayed smooth. This is the part that matters for Claude Code. A wheel notch in less emits a scroll-region index and one new row — a handful of dirty rows. Claude Code's fullscreen renderer repaints the entire viewport per notch, so it hits rows × forced reflow where less hits roughly 1 × forced reflow. My control test didn't disprove a terminal-side cause; it isolated the input that triggers it. At 3840×2160 with DPR 2 the row count is large, which is why it's this severe here.

What I think is still actionable for Claude Code

The VS Code setting is mine to fix and I've fixed it. But the reason this configuration is survivable in less and unusable in Claude Code is the full-viewport repaint per scroll notch. Emitting scroll-region / delta updates on wheel scroll instead of redrawing the whole alt screen would cut the per-frame row work by roughly the viewport height, and would also reduce cost on the normal path for anyone whose terminal has any per-row render overhead.

Happy for this to be retitled or closed as external if you'd rather not track the repaint strategy here. Flagging it because "screen reader mode makes Claude Code fullscreen unusable in the VS Code terminal" is a real trap — nothing surfaces the connection, and the obvious suspects (GPU acceleration, scroll drain, renderer choice) all lead away from it.

Residual I can't yet explain

The mechanism above accounts for the per-frame cost, but not cleanly for two observations: that the degradation outlives all input, and that sending a message restores responsiveness instantly. Queued wheel events draining at ~1s per frame would look like the first; I have no grounded explanation for the second. Not asserting a cause for either.

Corrections: scrolling is not required, and the "sending a message fixes it" claim is retracted

Two amendments to the original report. I've struck both claims in the issue body rather than silently editing them.

1. Retracting "sending a message instantly restores full responsiveness"

I originally called this "the most reliable signal in the whole repro." It isn't. On repeated observation it sometimes did nothing, and I can't produce it on demand. Anyone using it as a diagnostic lever should stop — I put it in the report with more confidence than the observation supported.

This also removes one of the two loose ends I flagged in the root-cause comment above. It was the observation that fit the mechanism worst, and it turns out not to be a real effect.

2. Scrolling is not required — repaint volume is the trigger

More useful correction. The degradation also happens with no mouse input at all, during ordinary streaming output where the view auto-scrolls by itself. The animated spinner glyph makes it easy to see: its frame rate visibly drops and stutters while nothing is being scrolled, selected, or clicked.

This matters for the diagnosis, because it fits the mechanism better than the original scroll-based framing did:

• The cost is rows × forced synchronous reflow, paid per render. Nothing about it is specific to wheel events.
• Wheel scrolling was never the cause — it was just the cheapest way to make fullscreen emit a full-viewport repaint many times per second.
• Streaming output plus an animated spinner produces the same repaint volume without any input, so it degrades the same way.
• It also explains "persists after all input stops" without needing a separate mechanism: in fullscreen the terminal is rarely idle, because the spinner keeps rendering.

So the trigger condition is repaint volume, not scroll input, and the less --mouse control test contrasts even more sharply than I first described: less dirties a row or two per notch via scroll regions and never sustains a repaint stream on its own, while fullscreen repaints the entire viewport continuously whenever anything is animating.

Effect on the ask

Unchanged, and slightly stronger. Emitting scroll-region and delta updates instead of full-viewport repaints would cut per-frame row work by roughly the viewport height — and the passive-streaming case shows that benefit applies during normal operation, not only while someone is scrolling.

I've retitled the issue to match, since the old title led with scrolling and ended with the retracted claim. It was previously:

[BUG] Fullscreen: scrolling up through a long conversation progressively degrades all input latency until the next message is sent (VS Code integrated terminal)

I think I found what makes this persist after input stops and clear on blur/keypress.

In screen reader mode, xterm.js's AccessibilityManager appends every printed character to an aria-live region and only stops after 20 line feeds. Fullscreen redraws by positioning the cursor, so it never hits that limit: the live region (a 1px-wide element) grows by every frame's text until the terminal loses focus or a key is pressed. Each append re-lays-out the whole thing, which fits the time you saw in Commit rather than JS.

Replaying recorded fullscreen scroll output into the xterm.js build VS Code 1.139 ships, the live region grew 145K → 611K → 977K chars over three 9 s loops, with main-thread stalls of 0.1 s → 3.1 s → 9.9 s. A blur cleared it. The per-row _alignRowWidth reflow was small by comparison (~50 ms per loop).

Fix proposed in xtermjs/xterm.js#6199. Until it ships, "editor.accessibilitySupport": "off" is the workaround, as you found.