desktop: fast redraws and resizes (GPU on, batched output, throttled resize) (0.2.4)

[ralyodio]

Anthony on KDE: "ui is a little glitchy, mainly the slow rendering on resizes, and screen redraws are really slow and visible … it needs to be fast".

Causes found

1. GPU: xterm 6 has no canvas renderer; fast means WebGL. Electron on Linux often blocklists the GPU (and under Wayland runs through XWayland), so panes silently fell back to the DOM renderer.
2. Output: every PTY read was its own IPC message and its own renderer task. A full-screen redraw arrives as dozens of reads, so you watched it being drawn piece by piece.
3. Resize: a refit on every animation frame reflowed 10k lines of scrollback each time, and resized the PTY on every frame. Over hqsh that makes the remote program redraw dozens of times a second.

Fixes

• ignore-gpu-blocklist, enable-gpu-rasterization, enable-zero-copy, and native Wayland (ozone-platform-hint=auto, WaylandWindowDecorations) when on Wayland. "gpu": false in ~/.config/hqterm/desktop.json opts out. GPU status is written to ~/.config/hqterm/desktop.log at startup.
• PTY output is coalesced per pane: one IPC message every 4 ms, or immediately at 256 KiB.
• Refit at most every 50 ms during a drag, plus a trailing fit. The PTY is resized only after 80 ms of quiet.
• A pane that can't get WebGL prints a one-line notice. A lost GPU context retries WebGL after 1 s instead of staying on the DOM renderer.

Version 0.2.4. A companion hqtui change follows: it will recognise TERM_PROGRAM=hqterm so hqtui apps (qc) send synchronized frames, which xterm 6 supports.

🤖 Generated with Claude Code