4 ms·

st has the highest input latency among quite a few terminal emulators [1] and feels thus very slugish. It's an ok piece of software at best. [1] https://danluu

by greyw 4y ago

st has the highest input latency among quite a few terminal emulators [1] and feels thus very slugish. It's an ok piece of software at best. [1] https://danluu.com/term-latency/ https://danluu.com/term-latency/

georgia_peach 4y ago
It's not a video game. I type programs in it. 30-110 ms is more than fast enough.
- greyw 4y ago
  The terminal emulator is probably the most used and most important software I'm running. It needs to be enjoyable. I personally can feel the lag so its not good enough for me. Anyway that being said I have some collegues that are not bothered by lagging mouse cursors and other janky stuff so I can somewhat understand that this might not matter to some people. edit: I just tried out st again on my gnu/linux machine and it seems to be fine with respect to input latency so I guess its not all too bad of a terminal emulator. Maybe it only sucks on macOS.
  - georgia_peach 4y ago
    It's probably what ninjin said -- XQuartz latency. I use it on Debian, and speed-wise, I can't tell the difference between st & the GPU-accelerated terminals. On Mac, I switched from iTerm2 to Apple's built-in terminal. It sips battery compared to all of the others.
ninjin 4y ago
I have used urxvt, st, and Alacritty extensively and I would say that to me they feel “snappy” in exactly that order. You are of course welcome to pick whatever metric you want to judge a piece of software, but I can not say that I have ever been bothered by st’s input latency. The input handling is done using XEvent and a call to pselect in x.c and I am sure a patch that does not increase the code complexity massively would be accepted upstream. Luu also had this to say about the experimental setup for st: > st on macOS was running as an X client under XQuartz. To see if XQuartz is inherently slow, I tried runes, another "native" Linux terminal that uses XQuartz; runes had much better tail latency than st and iterm2. Maybe it matters, maybe it does not. But I feel like picking your terminal comes down to a lot more than a single metric and input latency experiment.
AlanYx 4y ago
st is such an outlier in those measurements that it makes you wonder whether something is potentially wrong with the test setup. There's another set of latency measurements here: https://tomscii.sig7.se/2021/01/Typing-latency-of-Zutty https://tomscii.sig7.se/2021/01/Typing-latency-of-Zutty In those, st is roughly similar in performance to urvxt and Alacritty.
- Beltalowda 4y ago
  Also some measurements over here, which are yet again different: https://lwn.net/Articles/751763/ https://lwn.net/Articles/751763/ I guess accurately measuring latency is hard.

by greyw 4y ago

georgia_peach 4y ago

It's not a video game. I type programs in it. 30-110 ms is more than fast enough.

greyw 4y ago
The terminal emulator is probably the most used and most important software I'm running. It needs to be enjoyable. I personally can feel the lag so its not good enough for me. Anyway that being said I have some collegues that are not bothered by lagging mouse cursors and other janky stuff so I can somewhat understand that this might not matter to some people. edit: I just tried out st again on my gnu/linux machine and it seems to be fine with respect to input latency so I guess its not all too bad of a terminal emulator. Maybe it only sucks on macOS.
- georgia_peach 4y ago
  It's probably what ninjin said -- XQuartz latency. I use it on Debian, and speed-wise, I can't tell the difference between st & the GPU-accelerated terminals. On Mac, I switched from iTerm2 to Apple's built-in terminal. It sips battery compared to all of the others.

ninjin 4y ago

I have used urxvt, st, and Alacritty extensively and I would say that to me they feel “snappy” in exactly that order. You are of course welcome to pick whatever metric you want to judge a piece of software, but I can not say that I have ever been bothered by st’s input latency. The input handling is done using XEvent and a call to pselect in x.c and I am sure a patch that does not increase the code complexity massively would be accepted upstream. Luu also had this to say about the experimental setup for st: > st on macOS was running as an X client under XQuartz. To see if XQuartz is inherently slow, I tried runes, another "native" Linux terminal that uses XQuartz; runes had much better tail latency than st and iterm2. Maybe it matters, maybe it does not. But I feel like picking your terminal comes down to a lot more than a single metric and input latency experiment.

AlanYx 4y ago

st is such an outlier in those measurements that it makes you wonder whether something is potentially wrong with the test setup. There's another set of latency measurements here: https://tomscii.sig7.se/2021/01/Typing-latency-of-Zutty https://tomscii.sig7.se/2021/01/Typing-latency-of-Zutty In those, st is roughly similar in performance to urvxt and Alacritty.

Beltalowda 4y ago
Also some measurements over here, which are yet again different: https://lwn.net/Articles/751763/ https://lwn.net/Articles/751763/ I guess accurately measuring latency is hard.