17 ms·
How much faster are the Gnome 46 terminals?
- zokier 3y agoI really appreciate doing actual end-to-end tests! The VTE improvements look great, good job!
- PhilipRoman 3y agoFinally 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.
- aumerle 3y agoYou want better benchmarks look at the ones delivered bya ctual terminal developers, for example: https://sw.kovidgoyal.net/kitty/performance/#throughput https://sw.kovidgoyal.net/kitty/performance/#throughput or https://github.com/alacritty/vtebench/tree/master https://github.com/alacritty/vtebench/tree/master
- michaelt 3y agoThose 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.
- aumerle 3y agoThey are better in every regard compared to catting a large file, which is what the OP was complaining about. Certainly if you want to comprehensively understand terminal emulator performance there are multiple axes along which to measur eit and various tradeoffs involved. But I think nowadays we have much better alternatives to catting large files or running find / both of which have been the go to for measuring terminal performance for most people.
- tommi 3y agoWell written article and interesting results, thank you. I'm surprised that there has been input latency of tens of milliseconds with the said setup. How much are typical input latencies in comparable Windows laptops and Macs?
- YaLTeR 3y agoHey, I'm the author. Glad you enjoyed the post! I don't have any results for Windows or macOS yet unfortunately. I wanted to run these tests on Windows eventually, and include things like cmd.exe and the Windows Terminal. Maybe when I get around to re-benchmarking a wider range of terminals. Mac would certainly be interesting to include, but I don't have access to any of those.
- genewitch 3y agohttps://danluu.com/input-lag/ https://danluu.com/input-lag/
- zokier 3y agoI would encourage you to do these sort of tests yourself, the hardware involved is pretty inexpensive (I'd expect you should be able to get something for <$50)
- NelsonMinar 3y agoHere's recent testing of Windows terminal latencies. It's 66ms in Microsoft's fancy new terminal. https://chadaustin.me/2024/02/windows-terminal-latency/ https://chadaustin.me/2024/02/windows-terminal-latency/
- sprash 3y agoI would be interested in a comparision of uncomposited X11 running Xterm using this measurement method. Xterm outperforms everything "on paper" with typometer but is it really real?
- delusional 3y agoNot the author, but I did this same project a few years back, these were the results back then: https://jnsn.dev/posts/fastisslow/ https://jnsn.dev/posts/fastisslow/ with a guide https://github.com/DelusionalLogic/Frametime https://github.com/DelusionalLogic/Frametime if you want to replicate it.
- nickjj 3y agoI tried a bunch of terminals over the years. I never did tests that were as in depth as the OP's blog post but no terminal I've used ever matched how good Xterm feels when typing. It's like you're typing within a zero resistance system.
- sevg 3y agoI wonder how Kitty would do on these benchmarks. Kitty is a different beast to Alacritty and has tonnes of features (many of which I'm grateful for), but I wonder what the performance cost is.
- aumerle 3y agoThere is no performance cost, there is a performance gain: https://sw.kovidgoyal.net/kitty/performance/#throughput https://sw.kovidgoyal.net/kitty/performance/#throughput
- abhinavk 3y agoKitty was slower than alacritty and foot as per author's earlier input latency tests. https://mastodon.online/@YaLTeR/110837121102628111 https://mastodon.online/@YaLTeR/110837121102628111
- aumerle 3y agoThat's because kitty's default settings introduce a few ms of latency deliberately to save energy, see details at: https://sw.kovidgoyal.net/kitty/performance/#keyboard-to-screen-latency https://sw.kovidgoyal.net/kitty/performance/#keyboard-to-scr... If you want to do a fair comparison to alacritty you need to set those to the recommended values for best latency.
- reyqn 3y agoStill slower than alacritty according to https://beuke.org/terminal-latency/ https://beuke.org/terminal-latency/ Also not really cross-platform, contrary to what's indicated in the first word of its github description, and the owner is kind of an ass about it https://github.com/kovidgoyal/kitty/issues/6481 https://github.com/kovidgoyal/kitty/issues/6481.
- josefx 3y agoCross platform does not automatically mean something supports all platforms, nothing does.
- kazinator 3y agoI can notice a slight latency in Gnome Terminal ... running in a VM ... on a Windows host ... being accessed via RDP over Wi-Fi and a 100 Mbps line. Not enough to bother me.
- sscarduzio 3y agoI admire their results, their method, and their will to share them with us. But I have to agree with this: my eyes can't perceive any difference.
- spookie 3y agoIt's less about seeing and more about feeling when typing fast.
- internetter 3y agoYeah when I drop into a TTY because I broke something again, I always go woah, this thing feels instant
- deleted 3y ago[deleted]
- deleted 3y ago[deleted]
- kazinator 3y agoThe latency is literally about how late the pixels appear on the display, so it has to be about seeing. If you type fast, but still have to look at your output, it may be a good idea to wean off that; you should be able to type while reading something elsewhere on the screen, only occasionally glancing on what you're typing. Traditional typewriter typists had to be able to transcribe an existing written text (e.g. manuscript). That meant their eyes were on the text they were reading, not on their hands or the typewriter ribbon strike area.
- 3y ago
- tutfbhuf 3y agoJust recently, I did a terminal latency test with Typometer for the following terminals, sorted by lowest latency: xterm (389-1) alacritty (0.13.1-1) kitty-tuned (0.31.0-1) zutty (0.14-2) st (master 95f22c5) urxvt (9.31-4) konsole (24.02.0-1) kitty (0.31.0-1) wezterm (20230712.072601) gnome-terminal (3.50.1-1) xfce4-terminal (1.1.1-2) terminator (2.1.3-3) tilix (1.9.6-3) hyper (v3.4.1) I only tested for software latency (monitor, keyboard and other hardware latency is not included in Typometer benchmarks). I ran the test on Arch Linux with Xorg + bswpwm without compositor. You can find the full results on by blog https://beuke.org/terminal-latency/ https://beuke.org/terminal-latency/.
- kaba0 3y agoDoes it take into account Wayland, and its double-buffered nature (unless you specifically opt for disabling v-sync, see the presentation protocol)?
- Hendrikto 3y ago> I ran the test on Arch Linux with Xorg
- kaba0 3y agoMissed that part, sorry. I thought one of those terminal emulators were Wayland only, hence my question.
- Jonnax 3y agoIf the 16ms latency at 60hz bothers you. Then get a 120hz display which has 8ms latency. Or there's 240hz 4k displays with 4ms If that's not enough then there's 1080p esport monitors with 540hz so 1.85ms.
- kaba0 3y agoIt doesn’t bother me, I was just interested in whether the benchmark is fair in this respect (it is xorg only, so the answer is yes). I personally believe that 120+ hz gives barely any benefit, though.
- unwind 3y agoVery nice! 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/ https://www.benheck.com/xbox1monitor/
- blueflow 3y agoThe focus on performance is a recent thing. VTE was pretty slow to begin with.
- amaranth 3y agoThe focus on _latency_ is a recent thing. VTE was previously focused on throughput and low CPU usage, which are conflicting goals.
- bobmcnamara 3y agoFun fact: if you have vsync enabled, latency depends on where you position the sensor.
- nicolaslem 3y agoMy distro recently upgraded to Gnome 46 and as someone who spends a big chunk of their day in a terminal, the difference was very noticeable. Great work to everyone involved!
- sscarduzio 3y agoI appreciate the fine work done by developers and testers, however I've been using gnome-terminal for around two decades and never perceived the input latency. Like, I installed Alacritty some years ago side-by-side with gnome-terminal, and gosh, I could not visually sense any difference. Do I have bad sight?
- sidkshatriya 3y agoDepends on how much time you've spent in a terminal over the last two decades. Do you do software development in a terminal or an IDE ? If you develop in an IDE you don't "live" in a terminal and most likely it will not matter what terminal program you use and you won't notice latency.
- berkes 3y agoI live in my terminal. Very occasionally (once a week or less) do I open VS code or so. The rest of the 8+ hours a day I spend in vim, zsh and such. I don't perceive gnome-terminal as slow, or it's high latency. Alacritty did not show me any difference from gnome-terminal; other than that I needed to learn a lot of new stuff which I'm not going to do if there's no clear win. For me there was no clear win.
- zokier 3y agothere is lot of interesting stuff that could be measured here. Valves Gamescope is supposed to be this low-latency compositor, so it might be interesting to compare to more typical desktop compositors. Similarly testing VRR could have interesting results
- INTPenis 3y agoI 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.
- medstrom 3y agoI'm guessing you notice it more in some use-cases. Can anyone chime in with an example?
- abhinavk 3y agoLatency 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)
- aembleton 3y agoI'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.
- VeninVidiaVicii 3y agoLately I’ve been noticing some very fast flickering when I type on Gnome terminal. Guess this coincides with the new terminal.
- flexagoon 3y agoI'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.
- rocqua 3y agoHave you tried switching back? It is often more noticable when latency increases than when it decreases.
- prmoustache 3y ago>Test Setup # >I did all tests on this system: > Lenovo Legion 7 Gen 7 AMD with Ryzen 7 6800H CPU and Radeon RX 6700M dGPU (using the dGPU exclusively via the MUX switch). > Monitor: Acer Nitro XV320QU, 2560×1440, 144 Hz, using 100% scale. OK you can send these tests to the trashbin as this is so unrepresentative of what most users are using. This is sometimes infuriating. A year ago, I installed linux on my partner's computer, her HDD running windows had died. Things were seemingly working fine until I realized some apps (dnfdragora comes to mind) were unusable on her 1366x768 with 1.x ratio as they take way too much screen estate. I think worldwide there are still more than 20% of desktop users using screen resolutions with less than 768px of height and around 50% of user with less than 900px of height. I have not issue developpers using decent machines to develop, but when it comes to testing performance and usability they should also do it on that +10y old entry level laptop they probably still have sitting somewhere in a storage area. Or buy an old netbook for 20 bucks for that specific use.
- moooo99 3y agoI suppose someone who is running a ten year old system doesn’t tend to care too much about the input latency of their terminal emulator?
- prmoustache 3y agoIt is about testing in general. Also you never know, one patch that improve perf on latest gen systems might do the opposite on much more humble ones which still represent a sizable portion of the computer running today. It is important to know what you are gaining (or not) and where. And I don't agree about your initial premise. The fact one is running an old system that might be super slow on most js hungry websites, playing AAA ganes or compressing 4k videos doesn't mean slowness has to be expected on native and/or small or simple apps. Also, while we can expect an old computer to be slow at things it wasn't designed for like decompressing/compressing videos with much higher bitrate/resolutions, handling traffic with more cpu intensive encryption algorithm, we should not accept a computer being slower at things it was designed for and was working well a decade ago. My motorbike is probably marginally slower from wear and tear of its engine, yet still goes like stink at the green light and has no issue reaching the speed limits. My well maintain 35y old bicycle is still as fast as it ever was, even probably faster thanks to better tires. My oven and gas stoves are still heating my meal the same way it did before. Why should an old computer be slower at doing the same things? This is a disgrace and the whole IT industry should be ashamed of accepting and enabling this.
- mseepgood 3y agoCan anyone explain why a terminal needs "speed"? Isn't the limiting factor the typing and reading speed of the human in front of it?
- boxed 3y agoNot if you're tailing log files.
- vermilingua 3y agoNo, because the human does not need to process the entire screen contents with every frame, only the delta from the last frame (usually). Therefore getting those deltas into eyeballs as quickly as possible increases how quickly the human can interact with the computer.
- ufo 3y agoThis is more about responsiveness than batch-processing speed.
- dale_glass 3y agoThere are cases where this makes a big difference. For a dramatic example, consider the VESA framebuffer console, a slow serial link, or a bad SSH connection with a good CPU on the other end. With enough terminal output it will bottleneck whatever you're doing. Sometimes extremely dramatically so. To the point of adding hours to a task in really bad cases. For such situations, it often helps a lot to run remote tasks in something like screen and only switch to it to check progress once in a while.
- easytiger 3y ago> With enough terminal output it will bottleneck whatever you're doing. Sometimes extremely dramatically so. To the point of adding hours to a task in really bad cases. At the very laziest &> foo your output. Or preferably add logging to your application. Go back 20 years and you wouldn't have had the luxury of spewing hundreds of megabytes of text to a remote terminal for no reason.
- nolist_policy 3y agoThe VTE improvements are very noticeable on the Pinephone btw.
- yla92 3y agoNeat! Would love to see the benchmark to also include Mitchelle Hashimoto's Ghostty terminal when it comes out publicly. (now still under development/polishing stage and in private beta) https://mitchellh.com/ghostty https://mitchellh.com/ghostty
- l33tman 3y agoNot 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. And I prefer GUI terminals for this use-case...
- pxc 3y ago> And I prefer GUI terminals for this use-case... 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 https://github.com/tmux-plugins/tmux-resurrect (You can, of course, use tmux with any GUI terminal emulator you like.)
- johnchristopher 3y agoI suppose you could "just" run tmux and have more or less the same results (opened tabs with history, but won't survive a reboot) ?
- cqqxo4zV46cp 3y agoA lot leaning on “more or less”.
- Brian_K_White 3y agoA lot depends on what are the important parts. It could be essentially identical if it supplies all the parts you care about and don't actually care too much what exact form it takes. But if you require the same exact gui controls then sure, totally different and not even an answer to the question.
- johnchristopher 3y agoYeah, it's not the same experience. And you have to get into tmux configs which is a hassle by itself. I am not a fan of terminal multiplexers, I tend to forget them and when the server crashes or reboot it won't replay/restart what I was doing in those tabs anyway. I just use them for long running jobs I am testing. I also don't like the whole tmux window/pane manipulation you can do, I'd rather have my primary DM to do that well. It's funny how tmux is downvoted in those replies though :D.
- ghusbands 3y agoThey really need to start the y axis at 0 in those graphs - it's somewhat misleading how low some of the latency bars appear.
- dwheeler 3y agoHooray, with these changes, the tested setup finally manages to have a smaller input median latency (Console ~12 msec) than an Apple //e from 1983 (30 msec). It only took 41 years: https://www.extremetech.com/computing/261148-modern-computers-struggle-match-input-latency-apple-iie https://www.extremetech.com/computing/261148-modern-computer... https://danluu.com/input-lag/ https://danluu.com/input-lag/ 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/ 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.
- naikrovek 3y agoDealing 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?
- dwheeler 3y agoUnicode 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.
- plingbang 3y agoI used gnome-terminal for years and at the times when I had to switch to a virtual console, I often had a feeling that the latter was more responsive. But that could be the placebo effect due to higher cursor blinking and key repeat rates. My monitor is 60 Hz.
- eviks 3y ago> that is only really meant for testing. It is, however, quite useful for benchmarking, But not very useful for real users Although great that they are measuring real latency with a camera!
- alberth 3y agoGhostty I’m most interested in seeing the cross platform terminal named Ghostty, created by the creator of HashiCorp https://mitchellh.com/ghostty https://mitchellh.com/ghostty
- superkuh 3y agoSpeeding up the gnome terminal is useless whe you realize GNOME has been removing keyboard support features from Gtk since 2014. Try to copy a file path from that Gnome 46 terminal and do a File-Open operation in a Gtk application and ctrl-v<enter> to paste in the path and open it. Woops! Error! "The folder contents could not be displayed. Operation not supported" GNOME and Gtk3/4 no longer prioritize keyboard inputs and hide them behind complex key shortcuts. They let keyboard inputs bitrot and fail because they only care about GUI inputs. It's an open bug since 2014, opened and closed as wontfix literally dozens of times. Brought up in #gtk chat a similar amount. Latest (2023) wontfix: https://gitlab.gnome.org/GNOME/gtk/-/issues/5872 https://gitlab.gnome.org/GNOME/gtk/-/issues/5872
- zvmaz 3y ago> GNOME and Gtk3/4 no longer prioritize keyboard inputs and hide them behind complex key shortcuts I mainly use GNOME with the keyboard. I seldom use the mouse. I don't know about your specific workflow.
- superkuh 3y agoDo you really hit . or / and then backspace then paste when you want to paste a file path and enjoy it? That's at least 2 extra keystrokes. Even worse when you have to use the mouse to dismiss the pop-down closest file name list that prevents pasting.
- drewg123 3y agoPersonally, IDGAF about latency. I'm used to typing things into servers that are two crossings of a continent away (one for corp VPN entry, and then another one to get to a server 50 away via the cross-country VPN hop). What gets me is the performance when a terminal command spews an unexpectedly large amount of output and/or I forget to postpend less. Eg, the latency between ^C being entered and having an impact. This can be 10s of seconds on slower terminals like xterm and this is what finally got me to switch away from xterm to one of these new-fangled terminals like the one from lxde.
- enriquto 3y agoVery interesting! Do you have a specific test to measure this performance in different terminals?
- drewg123 3y agoI just made a big file (something like cat /usr/share/dict/words >> /tmp/zot a few times) and then just cat'ed that at the commandline
- enriquto 3y agoI cannot reproduce this with xterm(372). I build a file that needs 20 seconds to print whole, but I can stop it with ^C instantaneously anytime I try.
- p_b_d 3y agoI use xterm and i3wn on debian and I never experienced anything faster. Surely the idea of waste GPU for the terminal never even crossed my mind so alacritty is IMO overkill.
- taviso 3y agoI think I feel the same way, lag has never occurred to me when using xterm -- and I use the heavier features like translations and sixels day-to-day. Maybe it's just the Athena widget style that is making people dismiss it, because it's great.
- codedokode 3y agoSorry 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.
- bobmcnamara 3y agoIIRC, this was a feature from CMD.EXE
- lanstin 3y agoIt 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.
- bitvoid 3y agoThat 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.
- lbhdc 3y agoYou can change that in the settings. 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.
- kaanyalova 3y agoConsole, the newer gnome terminal remembers the window size.
- adrianmonk 3y agoI 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."
- larsrc 3y agoNice tests, but could you please use 0-based Y-axes in the charts? You're visually exaggerating the improvements.
- DiabloD3 3y agoI don't know what this has to do with "terminals", other than the author is using this to benchmark this. According to the author, Gnome 46's Mutter, when in direct mode (which windowed apps do not use, so the benchmark is partially invalid; useful for gamers, but not much else) is faster. Thats great. Gnome is now possibly as fast as all the wlroots-based Wayland WMs (Sway, River, Hyprland, etc) and KDE's Kwin. I've looked into why Mutter has historically been the worst WM on Linux for the longest time: it makes a lot of assumptions that "smoother == better", no matter the cost. OSX's WM does the same thing, so they felt justified. If you lag more than 1 frame, it is noticeable to non-gamers; ergo, a latency of between 16 and 32ms (since WMs do not full-time VRR, although they could, and maybe should) once the app flushes their draw commands; this is on top of whatever the app did, which may also be assuming 60hz. Modern WMs try to get latency down as far as possible, even implementing "direct mode" which directly displays the fullscreen app's framebuffer, instead of compositing it, thus zero latency added by the WM itself.
- kaba0 3y agoLower latency is not the ultimate goal. Energy efficiency, for example, is another important factor DEs have to optimize for, that can be negatively affected by lower latencies. Ultra-low latency on a laptop, that will poweroff in an hour is probably a bad tradeoff.
- DiabloD3 3y agoYou are mistaken on how much power any of this uses. Laptops are equipped with high refresh rate panels nowadays, this will someday become the norm.
- kaba0 3y agoLeaving the same buffer displayed a million times is cheap. Redoing it always from scratch, even if you arrive at the same result, is expensive. A good example of that would be retained vs immediate mode GUIs.
- 3y ago
- dyingkneepad 3y agoThe lack of mention to Linux's power management system during measurement is worrying. This is the kind of test that gets completely affected by Linux power management policies, up to the point where results may be meaningless.
- aidenn0 3y agoI remember many years ago, SBCL would build noticeably slower on gnome terminal as compared to xterm due to how verbose the build process was. I think they even put a note in the README about it.
- stinos 3y agoThis, 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.
- hinkley 3y agoIf I’m watching a screen scroll in real time I’m much more likely to be looking at the bottom third of the screen.
- tverbeure 3y agoIronically, a bug in mutter crept into Ubuntu 22.04 and later just a week ago. It increased the keyboard latency dramatically on some systems and made typing a pain. There's currently a bug fix with update trial packages. The solution presented here worked for me: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/2059847/comments/36 https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/205984...
- melolife 3y agoI had this issue and it appears to be fixed in the latest version of mutter available for Arch.
- robotburrito 3y agoIt'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 :)
- jethro_tell 3y agoHow 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.
- yjftsjthsd-h 3y agoIsn'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.
- pilcha 3y ago> terminal latency post > xterm not mentioned :sadface:
- Postosuchus 3y agoInteresting timing (pun intended): apparently one of the recent Gnome updates in Ubuntu made terminal barely usable due to lagging - https://askubuntu.com/questions/1509058/input-delay-on-terminal-ubuntu-22-04-4 https://askubuntu.com/questions/1509058/input-delay-on-termi... I've noticed this myself on my main rig running Ubuntu 22.04, which never ever had any perceptible lag. Now it is so bad I was forced to switch to Alacritty.
- bPspGiJT8Y 3y agoGnome terminal would also need some unicode handling improvements, its current score in `ucs-detect` rating is D-[0]. [0] https://ucs-detect.readthedocs.io/results.html https://ucs-detect.readthedocs.io/results.html