How much faster are the Gnome 46 terminals?
GNOME 46 brings substantial input-latency improvements to its VTE-based terminals, prompting renewed interest in how fast different Linux terminal emulators actually feel and perform. Commenters highlight that while benchmarks using hardware sensors show real gains—especially versus older GNOME releases—results depend heavily on compositor behavior, display refresh rates, and tuning choices, and don’t always match what typical users notice. The thread broadens into comparisons with xterm, Alacritty, Kitty and others, debates over latency vs. throughput and energy usage, and whether modern systems should strive to match the responsiveness of much older computers.
Benchmark methodology & scope
- Many welcome seeing a hardware-based, end‑to‑end latency test instead of the usual “cat a huge file” throughput benchmarks.
- Others point to existing tools (vtebench, Kitty’s own tests, Typometer) and note each stresses different aspects (throughput vs latency vs frame rate).
- Several ask for more terminals to be tested: native Linux console/TTY, xterm on uncomposited X11, foot, Kitty, Konsole, Ghostty, etc.
- Some question using “raw Mutter” direct mode rather than full GNOME Shell, arguing the results may be optimistic for real desktops.
Terminal comparisons and latency
- Shared Typometer results (Xorg, no compositor) rank xterm and alacritty at the top, with Kitty‑tuned close behind; many VTE‑based terminals (GNOME Terminal, xfce4-terminal, Tilix) are slower.
- Multiple comments say Kitty has excellent throughput but (by default) worse latency than alacritty/xterm; Kitty adds intentional delay for energy saving, tunable via config.
- Others mention wezterm, foot, Zutty, and note a general “rejuvenation” in terminal development, with several projects improving latency in recent years.
Perception and practical impact
- Some users immediately notice GNOME 46 terminal improvements; others say they cannot perceive any difference between “slow” and “fast” terminals even after years of heavy use.
- A common theme: latency is more “felt” than consciously seen, especially for fast typists, full‑screen terminals, and when switching to a TTY, which feels “instant.”
- Practical pain points include: cancelling massive output with Ctrl‑C, scrolling in editors, and tailing logs. Once latency is below a certain threshold, many believe further gains have diminishing returns.
Hardware, display, and measurement caveats
- Concerns about testing only on a modern 144 Hz gaming laptop/monitor; some argue legacy hardware should be checked, others reply that comparative results still hold.
- Discussion of 60 Hz vs high‑refresh displays, vsync, scanout position of the light sensor, and variability from keyboard latency; some prefer to exclude keyboard timing to focus on the terminal/compositor stack.
Broader ecosystem debates
- GNOME/Mutter criticized historically for prioritizing “smoothness” and frame scheduling over low latency; the old ~40 fps cap in VTE is cited as technical debt now being removed.
- Energy efficiency vs ultra‑low latency is debated, especially for laptops.
- Side discussions: whether running only on Unix‑like OSes counts as “cross‑platform,” GNOME/GTK keyboard‑unfriendly UX (e.g., path pasting), and VTE’s imperfect Unicode handling.