Hacker News Reader

Comment by DiabloD3 | Hacker News Reader

Summary:

1) Extremely fast GPU-accelerated terminals have a latency of slightly more than one frame due to only rendering once per frame (for performance and latency reasons).

2) Gnome-terminal sucks.

3) Old school terminals, like xterm, are extremely slow in practice, but look very fast on benchmarks like this, as they render on TTY input and do not wait (thus wasting time and latency rendering unseen changes).

4) This article is old, and misses out a lot of optimization work that has occurred on Alacritty.

5) The author of this article has a 60hz monitor. These numbers would be unreproducable on higher refresh monitors.

View on HN

A more recent test from last year still has not great latency numbers for Alacritty: https://www.lkhrs.com/blog/2022/07/terminal-latency/

Yeah, unfortunately he tested on OSX; notice all his numbers are bad, an unfortunate side effect of Apple unwilling (or unable) to focus on performance as a way to improve user experience and finally fix the compositor lag that's been there since the dawn of OSX.

But relatively speaking the conclusions remain the same, with kitty being one of the fastest.

Given the vast majority of the market has been and continues to be 60hz, their testing on a 60hz monitor isn't just understandable, it's highly relevant.

If a terminal program running on current low-end PC hardware can't handle updating/drawing within 1/60th of a second, something is very wrong.

Can you expand on (3)? It seems at first glance that the end-to-end testing (USB input through to monitor photon output) performed in this test captures the whole of the user's perception and experience.

you definitely will not get 3ms latency by measuring usb input through to monitor photon output on a 60hz or 120hz monitor, not even in xterm

i think you did not understand the article

Latency and throughput are not inverses, although they may exhibit anti-correlation over small ranges. A low latency does not imply high throughput. In particular xterm does not buffer input / rendering, so while individual keystrokes produce a response quickly, when there is a high volume of text the throughput will be lower than other approaches.

This will still feel laggy, just a different kind of lag to the one that you perceive using a high latency terminal.

For 1), aren’t there two gpu-based terminal emulators on that list with under 16ms latency on a 60Hz display. I think that should mean less than one frame but I don’t really understand the lack of variance in the measurements. I think if reported latencies are very low, the software methodology doesn’t work so well.

Am I missing something?

The only other GPU accelerated one I see is Kitty. Current Alacritty numbers are closer to Kitty than rxvt.

Kitty statically renders at 100hz, thus skews numbers a bit; however, this also proves all this guy measured was "time to next frame", not actual performance numbers.

Kitty is capped at 100fps by default, but you can speed it up at the cost of higher CPU usage:

https://sw.kovidgoyal.net/kitty/conf/#conf-kitty-performance

in the ideal case where every keystroke shows up in the next frame you should get an average of 8.3ms on a 60hz display, with a range from 0 (i did say this was ideal) to 16.7ms

Related to #1, has anyone tried rendering right before the compositor? That should allow sub-frame latency.

Alacritty is adding scheduled frames, a technique used by modern game engines to reduce frame variance and latency, hopefully in time for 0.13.

To get any better, you'd really want something like windowed VRR to consistently work on your target OS, and then any issues in Alacritty solved (if any) to take advantage of that.

Could you expand on what/how scheduled frames work?

> Gnome-terminal sucks

Does it? I just compared it to zutty and honestly couldn't tell a difference as far as input latency is concerned.

For me, the amenities of a Vte based terminal outweigh the slight negative of it being somewhat slow.

That said, not all Vte based terminals are equal, IIRC last time I had to hunt quite far to find one that handled some of the more esoteric key modifier combinations properly, and since then I've been settled on it (Sakura)

Reply on news.ycombinator.com