How's the latency? I've had to keep using xterm even though it kind of sucks just because it's got the lowest latency by quite a bit.

▲ ivanjermakov 7 hours ago | parent | next [-]

According to this (at least 11 months old) benchmark, Ghostty has the worst input latency across all contenders: https://github.com/moktavizen/terminal-benchmark?tab=readme-...

More benchmarks from 4 months ago: https://news.ycombinator.com/item?id=45253927

14 months old discussion of input latency in Ghostty with comments from the author: https://github.com/ghostty-org/ghostty/discussions/4837

▲

TehCorwiz 4 hours ago | parent [-]

I don’t type more than 100 characters a second so I’ve never ran into bits limits.

	▲	jstimpfle 3 hours ago \| parent [-]
		If you're typing just one character per second you'll still feel the difference. Latency is stress inducing.

▲ forty 7 hours ago | parent | prev | next [-]

I have been using computers and terminal for a long time, and this kind of comment makes me think I must have missed a whole bunch of things which can be done with a terminal

▲ kccqzy 6 hours ago | parent | prev | next [-]

Since people are mentioning latency I’ll mention throughput. Basically the idea is that you accidentally cat a large file to your terminal and we are measuring how much time it takes for the terminal to finish displaying it. This test generally favors GPU-accelerated terminals.

Ghostty performs very well on this regard, among the same league as Alacritty and Ptyxis.

▲

kazinator 4 hours ago | parent [-]

Rather, what will win is a terminal that internally builds an efficient, symbolic representation of what is on the display, rather than a pixel representation with all the font glyph, and which efficiently sychronizes that symbolic representation to the graphical canvas, skipping intermediate updates when the abstract display is changing too fast.

	▲	kccqzy 2 hours ago \| parent [-]
		That’s already happening I think. Newer terminals redraw at a fixed rate equal to the display refresh rate, usually 60Hz. But if there are more than 60 new characters being printed per second, some of these intermediate states are never rendered on screen.

▲ homebrewer 5 hours ago | parent | prev | next [-]

Have you tried kitty with more aggressive settings? It feels very responsive out of the box, but the defaults are balanced for sane energy use on portable machines.

  repaint_delay 5
  input_delay 1
  sync_to_monitor no

▲ 0sdi 7 hours ago | parent | prev [-]

on my machine, noticeable. I seriously tried it, but went back because I could notice a small end-end latency, between keypress and action. But I'm also 240hz user.

▲

kazinator 4 hours ago | parent [-]

Where are you measuring the keypress from? The nerve signal to your finger muscles?> Or the time the keycap hits bottom? What if the switch closes before the cap hits bottom: then we are getting a latency figure that looks better than it really is.

	▲	0sdi 2 hours ago \| parent \| next [-]
		Nerve signals yes. I just try them side by side, usually running vim on both terminals and measuring how it feels. If you can feel difference, the latency is bad.
	▲	jstimpfle 3 hours ago \| parent \| prev [-]
		I've had a keyboard like that and with it, xterm (and nothing else) felt like it was displaying the characters even slightly before I had pressed them. It was a weird sensation (but good)