4 ms·

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 l

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.

dan-robertson 3y ago
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?
- DiabloD3 3y ago
  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.
  - mrob 3y ago
    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 https://sw.kovidgoyal.net/kitty/conf/#conf-kitty-performance
- kragen 3y ago
  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
wmf 3y ago
Related to #1, has anyone tried rendering right before the compositor? That should allow sub-frame latency.
- DiabloD3 3y ago
  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.
  - kaba0 3y ago
    Could you expand on what/how scheduled frames work?
jyxent 3y ago
A more recent test from last year still has not great latency numbers for Alacritty: https://www.lkhrs.com/blog/2022/07/terminal-latency/ https://www.lkhrs.com/blog/2022/07/terminal-latency/
- DiabloD3 3y ago
  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.
  - canttestthis 3y ago
    But relatively speaking the conclusions remain the same, with kitty being one of the fastest.
KennyBlanken 3y ago
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.
runnerup 3y ago
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.
- kragen 3y ago
  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
- amoss 3y ago
  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.
streakfix 3y ago
> 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.
- NikkiA 3y ago
  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)

dan-robertson 3y ago

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?

DiabloD3 3y ago
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.
- mrob 3y ago
  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 https://sw.kovidgoyal.net/kitty/conf/#conf-kitty-performance
kragen 3y ago
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

wmf 3y ago

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

DiabloD3 3y ago
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.
- kaba0 3y ago
  Could you expand on what/how scheduled frames work?

jyxent 3y ago

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

DiabloD3 3y ago
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.
- canttestthis 3y ago
  But relatively speaking the conclusions remain the same, with kitty being one of the fastest.

KennyBlanken 3y ago

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.

runnerup 3y ago

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.

kragen 3y ago
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
amoss 3y ago
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.

streakfix 3y ago

> 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.

NikkiA 3y ago
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)