Reduce latency for echo output

[ruoso]

If the browser decides to defer the rendering of the frame for some reason, the echo from keystrokes can become somewhat sluggish, which can create visible latency in the experience.

In my tests, if we have a awaitingEcho boolean state that is set to true whenever we send to stdin, and then trigger a synchronous render when that is true (and immediately set it to false again), results in a much more responsive experience, and since we only do it when waiting for an echo, it shouldn't have any impact in the performance when there's a lot of content coming from stdout.

[diegosouzapw]

Hi @ruoso! 👋

Just wanted to let you know: this issue is fixed in diegosouzapw/ghostty-web v0.4.0 (see commit).
The canvas is now re-rendered synchronously after user input, so echo latency is minimized.

If you're looking for a fork with this and many other upstream fixes, feel free to give it a try!

I'm also building OmniRoute, an open project that provides free LLM model access — I plan to use ghostty-web there, so the more reliable it gets, the better. 🙏 Contributions welcome!

[alexellis]

Congrats on the project. This has got a lot of attention on X, so I finally gave it a try.

Not sure if it's related: https://x.com/alexellisuk/status/2059316250736562638?s=20

But I tried replacing xterm.js in superterm.dev ~ "tmux manager" and it was very laggy, typing in "ls -l" was painful. Not sure if #155 is related?

[ThomasK33]

Note

This triage report is AI-generated using Mux

1. Classification — feature (performance/UX improvement for terminal input echo). No outcome label is recommended; the behavior was narrowed to the current render/input code path, not a status:could-not-reproduce case.

2. Summary — The issue requests reducing perceived latency for echoed keystrokes. Today, user input is emitted through onData, the PTY echo later arrives through write(), and the canvas update is left to the next requestAnimationFrame render-loop tick. If the browser delays that frame, echo display can lag by an extra frame beyond the PTY round trip.

3. Evidence / reproduction —

   • Duplicate search with gh issue list --state all --search "echo latency" and --search "render latency" found only this issue.
   • A logic-level repro was run with a mocked WASM terminal and renderer: term.input('x', true) followed by term.write('x') writes the echoed byte to the terminal but does not call renderer.render() synchronously. Command: bun test /tmp/issue161-repro.test.ts → 1 pass, confirming the current code leaves painting to the queued render loop.
   • bun run typecheck passed.
   • Full browser/PTY dogfooding was not completed in this checkout because ghostty-vt.wasm is absent and the local zig shim is not configured (mise ERROR No version is set for shim: zig), so build:wasm/demo loading is blocked in this environment.

Minimal repro test used during triage

The local artifact was screened for secrets before summarizing. This is the equivalent test body with the import adjusted for placement under lib/:

import { describe, expect, test } from 'bun:test';
import { Terminal } from './terminal';

describe('issue #161 echo latency triage repro', () => {
  test('current write after user input does not synchronously call renderer.render()', () => {
    const term = new Terminal({ ghostty: {} as any });
    const written: Array<string | Uint8Array> = [];
    let renderCount = 0;

    (term as any).isOpen = true;
    (term as any).wasmTerm = {
      write: (data: string | Uint8Array) => written.push(data),
      readResponse: () => null,
    };
    (term as any).renderer = {
      render: () => {
        renderCount++;
      },
    };

    term.input('x', true);
    term.write('x');

    expect(written).toEqual(['x']);
    expect(renderCount).toBe(0);
  });
});

4. Relevant code / likely cause —

   • lib/terminal.ts creates the input handler and fires dataEmitter for keyboard input without recording that an echo is expected.
   • lib/terminal.ts paste() and input(data, true) also fire dataEmitter directly without an echo-pending marker.
   • lib/terminal.ts writeInternal() writes incoming PTY data to WASM, processes terminal responses, invalidates links, and then intentionally relies on the next animation frame (// Render will happen on next animation frame).
   • lib/terminal.ts startRenderLoop() continuously schedules rendering with requestAnimationFrame, so any browser rAF deferral directly delays visible echo.
   • lib/renderer.ts render() clears WASM dirty flags after painting, which means a targeted synchronous render for the first echo after input should leave the next rAF with little or nothing to redraw.

5. Recommendation — Implement the proposed echo-latency optimization behind a small internal state flag:

   • Add a private awaitingEcho/similar boolean on Terminal.
   • Set it immediately before firing dataEmitter for real user-input paths: the input-handler callback, paste(), and input(data, true).
   • In writeInternal(), after the WASM write/response handling and before returning, if awaitingEcho is true and renderer/WASM are available, clear the flag and call renderer.render(this.wasmTerm, false, this.viewportY, this, this.scrollbarOpacity) synchronously.
   • Add regression coverage proving the first write() after user input renders synchronously, the flag is cleared so subsequent bulk stdout does not render synchronously, and disabled stdin does not set the flag.
   • A previously linked fork commit appears to implement this exact pattern and can be used as prior art, but the fix should be adapted and tested against this repository’s current lib/terminal.ts.

6. Adjacent issues — No duplicate or distinct adjacent issue was found; no new issue was created.

---

Generated with mux • Model: openai:gpt-5.5 • Thinking: xhigh