But wait! Not so fast (smile). This benchmark uses the compositor "raw Mutter 46.0", not GNOME Shell. Raw mutter is "a very bare-bones environment that is only really meant for testing."
In addition, this measurement is not end-to-end because it does not include keyboard latency. In this test, the "board sends a key press over USB (for example, Space)". Latencies just within a keyboard can go up to 60msec by themselves:
https://danluu.com/keyboard-latency/
What are the true end-to-end numbers for the default configuration, which is the only situation and configuration that really matters? I wish the article had measured that. I suspect the numbers will be significantly worse.
I do congratulate the work of the GNOME team and the benchmarker here. Great job! But there are important unanswered questions.
Of course, the Apple //e used hardware acceleration and didn't deal with Unicode, so there are many differences. Also note that the Apple //e design was based on the older Apple ][, designed in the 1970s.
Still, it would be nice to return to the human resposiveness of machines 41+ years old.
I'd argue that it's actually a good thing that the author ignored keyboard latency. We all have different keyboards plugged into different USB interfaces plugged into different computers running different versions of different operating systems. Throw hubs and KVMs into the mix, too.
If the latency of those components varies wildly over the course of the test, it would introduce noise that reduces our ability to analyze the exact topic of the article - VTE's latency improvements.
Even if the latency of those components were perfectly consistent over the course of the author's test, then it wouldn't affect the results of the test in absolute terms, and the conclusion wouldn't change.
This exact situation is why differences in latency should never be expressed as percentages. There are several constants that can be normalized for a given sample set, but can't be normalized across an entire population of computer users. The author does a good job of avoiding that pitfall.
The Mutter thing is interesting. The author holds that constant, and GNOME sits on top of Mutter, so I think it's reasonable to assume we'd see the same absolute improvement in latency. GNOME may also introduce its own undesirable variance, just like keyboard latency. I'd be very curious to see if those guesses holds up.
> We all have different keyboards plugged into different USB interfaces plugged into different computers running different versions of different operating systems.
I've actually been curious about getting a wireless keyboard recently, but wondered about how big of a latency impact there would be. Normally I use IDEs that definitely add a bit of sluggishness into the mix by themselves, but something compounded on top of that would probably make it way more annoying.
Just found that interesting, felt like sharing. Might actually go for some wireless keyboard as my next one, if I find a good form factor. Unless that particular keyboard does something really well and most others just have way worse wireless hardware in them.
Then use the Apple 2e and forgo all the nicities of modern operating systems. Honestly this take is a whole lot of words to shit on all the open source devs working hard to provide things to us for free and I’m not having it.
+100. It's my least favorite talking point because I'm old enough to seen it linked 100 times, I find it very unlikely it was faster when measured by the same methods, and the article itself notes the funny math around CRTs.
Yet as a lover of Cherry Reds and Blues, in my opinion that time should most definitely be included. I am not a gamer, but I do notice the difference when I'm on a Red keyboard and when I'm on a Blue keyboard.
My initial gut reaction to this was - yeah, of course. But after reading https://danluu.com/keyboard-latency/ - I'm not so sure. Why exactly should physical travel time not matter? If a keyboard has a particularly late switch, that _does_ affect the effective latency, does it not?
I can sort of see the argument for post actuation latency in some specific cases, but as a general rule, I'm struggling to come up with a reason to exclude delays due to physical design.
Dealing with Unicode is not the challenge that people seem to believe it is. There are edge cases where things can get weird, but they are few and those problems are easily solved.
What really got my goat about this article is that prior to the latest tested version of Gnome, the repaint rate was a fixed 40Hz! Whose decision was that?
Unicode is more challenging when you're talking about hardware acceleration. On an Apple //e, displaying a new character required writing 1 byte to a video region. The hardware used that byte to index into a ROM to determine what to display. Today's computers are faster, but they must also transmit more bytes to change the character display.
That said, I can imagine more clever uses of displays might produce significantly faster displays.
> What really got my goat about this article is that prior to the latest tested version of Gnome, the repaint rate was a fixed 40Hz! Whose decision was that?
From a previous VTE weekly status message, leading up to the removal:
"I still expect more work to be done around frame scheduling so that we can remove the ~40fps cap that predates reliable access to vblank information." (from https://thisweek.gnome.org/posts/2023/10/twig-118/)
So as with a lot of technical debt, it's grounded in common sense, and long since past time it should have been removed. It just took someone looking to realise it was there and work to remove it.
I found the claim in the keyboard latency article suspicious. If keyboards regularly had 60ms key press to USB latency, rhythm games will be literally unplayable. Yet I never had this kind of problem with any of the keyboards I have owned.
Real physical acoustic pianos have a latency of about 30ms (the hammer has to be released and strike the string).
Musicians learn to lead the beat to account for the activation delay of their instrument - drummers start the downstroke before they want the drum to sound; guitarists fret the note before they strike a string… I don’t think keyboard latency would make rhythm games unplayable provided it’s consistent and the feedback is tangible enough for you to feel the delay in the interaction.
For rhythm games, you want to minimize jitter, latency doesn't matter much. Most games usually have some kind of compensation, so really the only thing that high latency does is delay in visual feedback, which usually doesn't matter that much as players are not focusing on the notes they just played. And even without compensation, it is possible to adjust as long as the latency is constant (it is not a good thing though).
It matters more in fighting games, where reaction time is crucial because you don't know in advance what your opponent is doing. Fighting game players are usually picky about their controller electronics for that reason, the net code of online games also gets a lot of attention.
In a rhythm game, you usually have 100s of ms to prepare you moves, even when the execution is much faster. It is a form of pipelining.
I don't buy the 60ms latency either, but it's very easy to compensate for consistent latency when playing games, and most rhythm games choreograph what you should do in "just a moment" which is probably at least 10x more than 60ms
Rhythm games will often have compensation for the delays of the input, audio, and visuals. Some do this without telling the users, others do it explicitly, e.g. Crypt of the Necrodancer.
The latency of the physical key going down is counted in that post, so it includes mechanical "latency" that will differ depending on how hard you press the keys and if you fully release the key.
> a smaller input median latency (Console ~12 msec) than an Apple //e from 1983 (30 msec).
> Still, it would be nice to return to the human resposiveness of machines 41+ years old.
A while ago someone posted a webpage where you could set an arbitrary latency for an input field, and while I don't know how accurate it was, I'm pretty sure I remember having to set it to 7 or 8ms for it to feel like xterm.
BTW, remember, most people still have 60hz monitors. Min latency can only be 16.6ms, and "fast as possible" is just going to vary inbetween 16.6 and 33.3ms.
The real improvement wouldn't be reducing latency as much as allowing VRR signaling from windowed apps, it'd make the latency far more consistent.
>BTW, remember, most people still have 60hz monitors. Min latency can only be 16.6ms, and "fast as possible" is just going to vary inbetween 16.6 and 33.3ms.
No the minimum will be 0ms, since if the signal arrives just before the monitor refreshes then it doesn't need to wait. This is why people disable VSync/FPS caps in videogames - because rendering at higher than <60FPS> means that the latest frame is more up-to-date when the <60Hz> monitor refreshes.
The maximum monitor-induced latency would be 16.6ms. Which puts the average at 8.3ms. Again, not counting CPU/GPU latency.
33.3ms would be waiting about two frames, which makes no sense unless there's a rendering delay.
Best-case median latency @60hz is 8.3ms (i.e. if there were 0 time consumed by the input and render, it would vary equidistributed between 0 and 16.6ms.
Xfce always felt like Linux to me. Like sure, there are other interfaces, but this is the Linux one.
I want an ARM laptop with expandable memory, user-replaceable battery, second SSD bay, and a well-supported GNU/Linux OS that has xfce as the UI - from the factory. That's the dream machine.
Xfce was my favorite until I found i3/sway. Even more responsive, and less mouse required since everything is first and foremost a keyboard shortcut, from workspace switching to resizing and splitting windows.
XFCE's goal is also implement a stable, efficient, and versatile DE that adheres to standard desktop conventions, rather than to import all of the limitations and encumbrances of mobile UIs onto the desktop in the mistaken belief that desktop computing is "dead".
Well, the Apple II had a 280x192 display (53 kpixel), and my current resolution (which is LoDPI!) is 2560x1600 (4 Mpixel). When you phrase it as "in 2024 we can render 76x the pixels with the same speed" it actually sounds rather impressive :)
Yeah, one of those is that modern stacks often deliberately introduce additional latency in order to tackle some problems that Apple IIe did not really have to care about. Bringing power consumption down, less jitter, better hardware utilization and not having visual tearing tend to be much more beneficial to the modern user than minimizing input-to-display latency, so display pipelines that minimize latency are usually only used in a tiny minority of special use-cases, such as specific genres of video games.
It's like complaining about audio buffer latency when compared to driving a 1-bit beeper.
The changes described in the OP are unequivocally good. But the most promoted comment is obviously something snarky complaining about a tangential issue and not the actual thing the article’s about.
It's an interesting observation, and it's constructive, providing actual data and knowledge. I downvoted you for negativity because you're providing nothing interesting.
I love both the underlying focus on performance by the VTE developers, and the intense hardware-driven measurement process in the article!
The use of a light sensor to measure latency reminded me of Ben Heck's clearly named "Xbox One Controller Monitor" [1] product [1] which combines direct reading of game console controller button states with a light sensor to help game developers keep their latency down. It looks awesome, but it's also $900.
This, and the linked article, show the photo sensor halfway the monitor. Nothing wrong with that for comparing measurements, but for quite a lot (possibly the majority) of typical monitors out there that actually means for a refresh of 60Hz putting the sensor at the top of the screen will give you about 8mSec faster and at the bottom 8mSec slower measurements because pixels / lines thereof are driven top to bottom. Like a CRT basically. So if you're getting into the details (just like where to put the threshold on the photo sensor signal to decide when the pixel is on) that should probably be mentioned. Also because 8mSec is quite the deal when looking at the numbers in tha article :)
Likewise just saying 'monitor x' is 30mSec slower than 'monitor y' can be a bit of a stretch; it's more like 'I measured this to be xxmSec slower on my setup with settings X and Y and Z'. I.e. should also check if the monitor isn't applying some funny 'enhancement' adding latency with no perceivable effect but which can be turned off, whether when switching monitors your graphics card and/or its driver didn't try to be helpful and magically switched to some profile where it tries to apply enhancements, corrections, scaling and whatnot which add latency. All without a word of warning from said devices usually, but these are just a couple of the things I've seen.
It's crazy to me we exist in a world where we can render hyper realistic 3d scenes and play games that once felt like they would be impossible to render on consumer grade hardware AND in the world where we are still trying to perfect putting text on a screen for a terminal LOL :)
Isn't some of it that we're optimizing more for graphics and there are tradeoffs between the two (so getting better at graphics tends to make the text worse)? Partially offset by terminals using GPU acceleration, but you're still paying for that pipeline.
How much of this includes that fact that a) it didn't matter too much previously, I.e. it works and b) until recently there's been a lot of network latency to solve for in a lot of terminal use cases.
Not related to the speed, but is there any terminal for Linux that works like the Mac OSX terminal, in that you can shut it down and restart and it will bring up all the tabs and their cmd histories and scrollbacks for each tab? They do that by setting different bash history files for each tab etc.
This is pretty tangential, but I just (1 hour ago) found out that iterm2 on Mac can integrate with tmux [1] if you run tmux with the argument "-CC", in a way that makes your tmux sessions map to the GUI windows / tabs in iterm2, including when using tmux on a remote machine via ssh.
I'm really excited about this, since I always forgot the hotkeys/commands for controlling tmux.
> They do that by setting different bash history files for each tab etc.
I wonder what happens when you close all the tabs, and then open a new one. Are all the tabs history merged back into a "general" history file when you close them, so you will get access to its commands in new ones?
This. I was just looking for the exactly the same thing. For now I use tmux with tmux-ressurect to persist state between reboots. - It works okeyish, I would say it's a good hack but still a hack. It's sad there isn't really solution for this problem maybe aside for warp. My little UX dream is to have such a solution of saveing workspaces integrated with whole OS and apps inside it. - That would be cool.
I find it more preferable to setup bash (or whatever shell you are using) to append into .BASH_HISTORY file at every command. You don't always remember on which tab/pane/window you type which command and most people would do Ctrl + R or use a fuzzy search tool anyway.
Also many times you open a new tab/pane/window and would like to access the history of another one who is already busy running a job so a common history is usually preferrable.
At the time mac os got that functionality their macbooks had removeable batteries.
One fun fact: you could just remove the battery while your apps where running and when booting up again every window you had open would just reopen with everything you had typed saved to disk in case of the iwork apps.
While I fully believe this could work, seems like it might need to be a temp solution. Ripping out the battery seems like a solution that might have more downsides than advantages.
You can do the saving part automatically by setting a different history file automatically for each instance of the shell, for example using a timestamp on your rc file and force them to append after every command.
Then if you open a new shell and want history from a particular older shell you can do `history -r <filename>`
So it is an hybrid automatically saved, manually recovered mode.
I used Gnome for years, then switched to sway and alacritty 2 years ago and honestly I can't tell any difference. I guess this is just like high end audio equipment, my ears/eyes are not tuned to the difference.
I've been using Gnome for years and am currently on Gnome 46. I hadn't noticed any difference in the terminal latency from Gnome 45. Like you, I think I just don't notice these things.
I'm on Gnome, and I moved from Gnome Console to Wezterm because of the latency. It wasn't noticeable when I used terminal as a small window, but most of the time my terminal was fullscreen, and the delay was unbearable.
Not a fair comparison, probably, but I swore off of gnome-terminal ~20 years ago because it was using half of my cpu while compiling a kernel. Xterm used ~2%.
To be fair even up to this day and on a modern Linux setup (Ryzen 7000 series CPU), that's still how Gnome terminal (before the patch in TFA are applied) does feel compared to xterm.
Maybe your screen and/or keyboard is adding enough latency that you'll never get good results no matter what software you use. The difference between bad latency and very bad latency isn't so obvious. Have you tried gaming hardware?
Latency adds up. When I had to work with a not-so-fast monitor (60Hz, mediocre processing and pixel-response lag), it became very apparent to point of annoyance. Using alacritty helped a bit. Our brains adapt quickly but you also notice it when switching frequently between setups. (Monitor or terminal emulators)
Finally a terminal benchmark that isn't just cat-ing a huge file. Would love to see the same test with a more diverse set of terminals, especially the native linux console.
Those tend to say things like "This benchmark is not sufficient to get a general understanding of the performance of a terminal emulator. It lacks support for critical factors like frame rate or latency. The only factor this benchmark stresses is the speed at which a terminal reads from the PTY."
So although those tests may be more extensive, they're not "better" in every regard.
Of course it's perfectly reasonable to want a benchmark that people can run without needing to build any custom hardware.
Sorry for being off-topic but what I dislike the most about Gnome Terminal is that it opens a small window by default (like 1/4 of my screen size) and even if you resize it, it doesn't remember the size after restart. It turns out you need to go to settings and manually specify how many columns and rows do you want.
That behavior is pretty common with many terminals. Off the top of my head, I know the default macOS Terminal and Windows Terminal both behave like that where you need to change the default dimensions in the settings.
I personally prefer having the dimensions set to a default size and then resizing specific windows that require more space. But it should at least be an option to have it remember resizes.
I often have many terminals open of various sizes. It's not clear what size would be the correct one to remember.
Therefore, I don't want it to try. It's fine for software to try to be smart if there's high confidence it knows what you want. Otherwise, it's yet another case, "Look, I automatically messed things up for you. You're welcome."
It is just old school terminal behavior. Even xterm iirc 25 lines 80 columns. That natural screen size. See also natural terminal colors green letter with black background.
Readit News
But wait! Not so fast (smile). This benchmark uses the compositor "raw Mutter 46.0", not GNOME Shell. Raw mutter is "a very bare-bones environment that is only really meant for testing."
In addition, this measurement is not end-to-end because it does not include keyboard latency. In this test, the "board sends a key press over USB (for example, Space)". Latencies just within a keyboard can go up to 60msec by themselves: https://danluu.com/keyboard-latency/
What are the true end-to-end numbers for the default configuration, which is the only situation and configuration that really matters? I wish the article had measured that. I suspect the numbers will be significantly worse.
I do congratulate the work of the GNOME team and the benchmarker here. Great job! But there are important unanswered questions.
Of course, the Apple //e used hardware acceleration and didn't deal with Unicode, so there are many differences. Also note that the Apple //e design was based on the older Apple ][, designed in the 1970s.
Still, it would be nice to return to the human resposiveness of machines 41+ years old.
If the latency of those components varies wildly over the course of the test, it would introduce noise that reduces our ability to analyze the exact topic of the article - VTE's latency improvements.
Even if the latency of those components were perfectly consistent over the course of the author's test, then it wouldn't affect the results of the test in absolute terms, and the conclusion wouldn't change.
This exact situation is why differences in latency should never be expressed as percentages. There are several constants that can be normalized for a given sample set, but can't be normalized across an entire population of computer users. The author does a good job of avoiding that pitfall.
The Mutter thing is interesting. The author holds that constant, and GNOME sits on top of Mutter, so I think it's reasonable to assume we'd see the same absolute improvement in latency. GNOME may also introduce its own undesirable variance, just like keyboard latency. I'd be very curious to see if those guesses holds up.
I've actually been curious about getting a wireless keyboard recently, but wondered about how big of a latency impact there would be. Normally I use IDEs that definitely add a bit of sluggishness into the mix by themselves, but something compounded on top of that would probably make it way more annoying.
A quick search lead me to this site: https://www.rtings.com/keyboard
It does appear that they have a whole methodology for testing keyboards: https://www.rtings.com/keyboard/tests/latency
For what it's worth, it seems that well made keyboards don't have too much latency to them, even when wireless (though the ones that use Bluetooth are noticeably worse): https://www.rtings.com/keyboard/1-3-1/graph/23182/single-key...
Just found that interesting, felt like sharing. Might actually go for some wireless keyboard as my next one, if I find a good form factor. Unless that particular keyboard does something really well and most others just have way worse wireless hardware in them.
https://www.youtube.com/watch?v=nbu3ySrRNVc explains it and has some statistics.
I can sort of see the argument for post actuation latency in some specific cases, but as a general rule, I'm struggling to come up with a reason to exclude delays due to physical design.
What really got my goat about this article is that prior to the latest tested version of Gnome, the repaint rate was a fixed 40Hz! Whose decision was that?
That said, I can imagine more clever uses of displays might produce significantly faster displays.
From a previous VTE weekly status message, leading up to the removal:
"I still expect more work to be done around frame scheduling so that we can remove the ~40fps cap that predates reliable access to vblank information." (from https://thisweek.gnome.org/posts/2023/10/twig-118/)
So as with a lot of technical debt, it's grounded in common sense, and long since past time it should have been removed. It just took someone looking to realise it was there and work to remove it.
Musicians learn to lead the beat to account for the activation delay of their instrument - drummers start the downstroke before they want the drum to sound; guitarists fret the note before they strike a string… I don’t think keyboard latency would make rhythm games unplayable provided it’s consistent and the feedback is tangible enough for you to feel the delay in the interaction.
It matters more in fighting games, where reaction time is crucial because you don't know in advance what your opponent is doing. Fighting game players are usually picky about their controller electronics for that reason, the net code of online games also gets a lot of attention.
In a rhythm game, you usually have 100s of ms to prepare you moves, even when the execution is much faster. It is a form of pipelining.
Some of them will batch multiple key presses over a slower connection interval, maybe 60ms, then the radio to USB converter blasts them over together.
So you can still type fast, but you absolutely cannot play rhythm games.
> Still, it would be nice to return to the human resposiveness of machines 41+ years old.
A while ago someone posted a webpage where you could set an arbitrary latency for an input field, and while I don't know how accurate it was, I'm pretty sure I remember having to set it to 7 or 8ms for it to feel like xterm.
The real improvement wouldn't be reducing latency as much as allowing VRR signaling from windowed apps, it'd make the latency far more consistent.
No the minimum will be 0ms, since if the signal arrives just before the monitor refreshes then it doesn't need to wait. This is why people disable VSync/FPS caps in videogames - because rendering at higher than <60FPS> means that the latest frame is more up-to-date when the <60Hz> monitor refreshes.
The maximum monitor-induced latency would be 16.6ms. Which puts the average at 8.3ms. Again, not counting CPU/GPU latency.
33.3ms would be waiting about two frames, which makes no sense unless there's a rendering delay.
Without it, you can race the scanout and minimum latency can get well under 1ms.
This was required for me to get a video stream down below 1 frame of latency.
Don't even attempt to use a modern windows install, you end up feeling that it is actually broken!
I want an ARM laptop with expandable memory, user-replaceable battery, second SSD bay, and a well-supported GNU/Linux OS that has xfce as the UI - from the factory. That's the dream machine.
Yeah, one of those is that modern stacks often deliberately introduce additional latency in order to tackle some problems that Apple IIe did not really have to care about. Bringing power consumption down, less jitter, better hardware utilization and not having visual tearing tend to be much more beneficial to the modern user than minimizing input-to-display latency, so display pipelines that minimize latency are usually only used in a tiny minority of special use-cases, such as specific genres of video games.
It's like complaining about audio buffer latency when compared to driving a 1-bit beeper.
The changes described in the OP are unequivocally good. But the most promoted comment is obviously something snarky complaining about a tangential issue and not the actual thing the article’s about.
This is obviously an improvement, who cares if it is not perfect by your standards?
Deleted Comment
Dead Comment
I love both the underlying focus on performance by the VTE developers, and the intense hardware-driven measurement process in the article!
The use of a light sensor to measure latency reminded me of Ben Heck's clearly named "Xbox One Controller Monitor" [1] product [1] which combines direct reading of game console controller button states with a light sensor to help game developers keep their latency down. It looks awesome, but it's also $900.
[1]: https://www.benheck.com/xbox1monitor/
Likewise just saying 'monitor x' is 30mSec slower than 'monitor y' can be a bit of a stretch; it's more like 'I measured this to be xxmSec slower on my setup with settings X and Y and Z'. I.e. should also check if the monitor isn't applying some funny 'enhancement' adding latency with no perceivable effect but which can be turned off, whether when switching monitors your graphics card and/or its driver didn't try to be helpful and magically switched to some profile where it tries to apply enhancements, corrections, scaling and whatnot which add latency. All without a word of warning from said devices usually, but these are just a couple of the things I've seen.
And I prefer GUI terminals for this use-case...
I'm really excited about this, since I always forgot the hotkeys/commands for controlling tmux.
[1] https://iterm2.com/documentation-tmux-integration.html
I wonder what happens when you close all the tabs, and then open a new one. Are all the tabs history merged back into a "general" history file when you close them, so you will get access to its commands in new ones?
A bit kludgy, but works good enough for me.
https://github.com/tmux/tmux/wiki
This probably isn't to your liking, then, but perhaps it will be of use to someone else: https://github.com/tmux-plugins/tmux-resurrect
(You can, of course, use tmux with any GUI terminal emulator you like.)
Also many times you open a new tab/pane/window and would like to access the history of another one who is already busy running a job so a common history is usually preferrable.
YMMV of course.
[1] https://tabby.sh/
[2] https://github.com/eugeny/tabby
One fun fact: you could just remove the battery while your apps where running and when booting up again every window you had open would just reopen with everything you had typed saved to disk in case of the iwork apps.
https://www.warp.dev/
Might not be 1:1 what you ask for, but it can do scrollbacks for sure and has very advanced command history features.
Then if you open a new shell and want history from a particular older shell you can do `history -r <filename>`
So it is an hybrid automatically saved, manually recovered mode.
Deleted Comment
- Closed source
- Requires an account to use
- Collects your data
No, thanks. There are plenty of superior options out there.
Things may, at long last, get better now.
or https://github.com/alacritty/vtebench/tree/master
So although those tests may be more extensive, they're not "better" in every regard.
Of course it's perfectly reasonable to want a benchmark that people can run without needing to build any custom hardware.
I personally prefer having the dimensions set to a default size and then resizing specific windows that require more space. But it should at least be an option to have it remember resizes.
Hamburger menu > Preferences > The name of your profile (mine is just called "Unnamed").
Changing the "initial terminal size" will do what you want. I have mine set to 132x43.
Therefore, I don't want it to try. It's fine for software to try to be smart if there's high confidence it knows what you want. Otherwise, it's yet another case, "Look, I automatically messed things up for you. You're welcome."