Startup regression: ~1.4s delay in v0.1.0-alpha.21 due to terminal probing

[tensor-r]

Summary

After upgrading from v0.1.0-alpha.20 to v0.1.0-alpha.21, the app now takes ~1.4 seconds before rendering the first frame. On v0.1.0-alpha.20 it was immediate.

Observed behavior

• alpha.20: First frame renders instantly. Streaming data appears as 1/1 on the first frame.
• alpha.21: First frame renders after ~1.4s. By then, streaming data has already buffered — the first frame shows 1/14 (14 entries accumulated during the delay), confirming the app was several frames behind.

This happens both with piped stdin and with static file input.

Likely cause

v0.1.0-alpha.21 includes a new terminal capability detection system (zr_detect.c, added in ae6fdfb) that sends DA1/DA2/XTVERSION escape sequences at engine startup and waits up to 500ms for responses (ZR_DETECT_TOTAL_TIMEOUT_MS = 500).

Additionally, createApp.ts now awaits loadTerminalProfile(backend) after backend.start() resolves, adding an async round-trip to the worker before the first render.

Request

Could there be a way to opt out of terminal probing at startup (e.g. createNodeBackend({ skipDetect: true })) for apps that don't use graphics features? Or could the profile detection be deferred so the first frame renders immediately while probing happens in the background?

Environment

• Runtime: Bun 1.3.9
• OS: Linux 6.17.0-14-generic
• Terminal: Ghostty

[tensor-r]

Can confirm still reproducible on version v0.1.0-alpha.33

[ppamorim]

Not happening on macOS thought.

[tensor-r]

Below I did some analysis and investigation:

Timing on GNOME Terminal / VTE 0.76 (default on Ubuntu 25.10):

backend.start():        1418ms   ← almost entirely zr_detect_probe_terminal()
loadTerminalProfile():    1ms
first view():           1423ms
first frameDone:        1452ms

Regression in v0.1.0-alpha.21: v0.1.0-alpha.20...v0.1.0-alpha.21

The problem: VTE does not respond to XTVERSION (\x1b[>0q) — support was reverted in 2022. The probing loop gets DA1/DA2/DECRQM responses quickly but then burns through the full ZR_DETECT_TOTAL_TIMEOUT_MS = 500ms waiting for a response that never arrives.

Three possible fixes (not mutually exclusive):

1. Allow disabling probing entirely. A config option like detectTerminal: false on createNodeBackend() or createApp(). Most apps don't use graphics/extended styles and don't need the probe at all. This is the simplest fix and gives app authors full control.

2. Don't block render on probing. Start with baseline/conservative caps, render the first frame immediately, and run zr_detect_probe_terminal() asynchronously. If the probe results change capabilities, trigger a re-render. Most apps don't use graphics features on frame 1, so the visual difference would be zero.

3. Early exit with DA1 sentinel. Once DA1 responds, all prior queries the terminal supports have already been answered. Do one short final read (~10-20ms) and bail. This is the established pattern used by terminal-colorsaurus and others. Would bring the probe itself to ~20-50ms.

Hopefully @RtlZeroMemory can find some time to patch, as many people use Ubuntu with the default terminal so a TUI taking 1s TTFR (time to first render) is a blocker for me. :(