perf: synchronous render after user input to cut echo latency

[diegosouzapw]

Summary

Fixes upstream issue #161: when a browser tab defers requestAnimationFrame, the gap between sending a keystroke and seeing the echoed character grows by up to one frame on top of the actual PTY round-trip — typing feels laggy.

Mechanism

• New private field awaitingEcho (boolean, default false).
• Set to true at the three points where input leaves the terminal:
  • The internal input-handler callback that fires dataEmitter on a keystroke
  • paste(data) (bracketed and unbracketed paths)
  • input(data, wasUserInput=true) (public API)
• At the end of writeInternal, if the flag is true, the renderer is called synchronously (then the flag is cleared). The rAF loop sees a clean buffer on its next tick — no extra cost beyond one render per keystroke.

This matches the reporter's recommended approach. The optimization is keyed off USER input only, so high-volume stdout (long builds, tail -f, etc.) is unaffected.

Attribution

Thanks to @ruoso for the report and the specific fix sketch.

Test plan

• bun run fmt && bun run lint && bun run typecheck
• bun test — 340 tests pass (1 new regression test for sync-render behaviour), 0 fail
• bun run build:lib
• bun run build:wasm (no WASM change, but rebuilt locally to confirm CI compat)
• Manual smoke test pending in bun run dev: type fast in a real shell, confirm subjective latency drop

Risk

Low. One extra renderer.render() per keystroke (cheap — the renderer already skips clean rows via dirty tracking). No impact on the bulk-stdout path.

[sonarqubecloud]

Quality Gate failed

Failed conditions
23.8% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

[gemini-code-assist]

Code Review

This pull request introduces an optimization to reduce perceived echo latency by performing a synchronous render immediately after user input is processed, rather than waiting for the next requestAnimationFrame tick. A new test suite has been added to verify that synchronous rendering occurs as expected. Feedback indicates that this synchronous render path currently bypasses cursor movement tracking, which could lead to delayed onCursorMove events; it is recommended to synchronize the cursor state and fire the corresponding event within this new logic block.

[gemini-code-assist]

While this synchronous render correctly addresses echo latency, it bypasses the cursor movement tracking logic present in the main render loop. This could result in a delay of up to one frame for onCursorMove events after a keystroke, as the next requestAnimationFrame tick will be the one to detect the change and fire the emitter. Consider checking for cursor movement here as well to keep the state and events fully synchronized with the visual update.

    if (this.awaitingEcho && this.renderer && this.wasmTerm) {
      this.awaitingEcho = false;
      this.renderer.render(this.wasmTerm, false, this.viewportY, this, this.scrollbarOpacity);

      // Sync cursor state and fire event if it moved during this sync render
      const cursor = this.wasmTerm.getCursor();
      if (cursor.y !== this.lastCursorY) {
        this.lastCursorY = cursor.y;
        this.cursorMoveEmitter.fire();
      }
    }