More Optimizations Made For Making GNOME/VTE Terminals Go Faster

[dEnigma]

While at the time he didn't plan to pursue it further, in the weeks since he's been making enhancements to GNOME's VTE code that is used by GNOME Console and other apps.

That's not quite right. To quote the man himself:

I didn't plan on working on the prototype further. The goal from the beginning was always to improve VTE.

(emphasis mine)

https://www.phoronix.com/forums/forum/software/desktop-linux/1413342-gnome-s-vte-seeing-improvements-for-faster-terminal-performance?p=1413370#post1413370

[treba]

I'm super happy about these improvements - they will improve battery life for everyone working a lot in the terminal and also reduce the noise in top and the like, making it easier to see how much cpu is used by other apps. Also worth mentioning is partial damage support, allowing compositors to reduce the area on screen they need to redraw. This post says it pretty well: https://fosstodon.org/@hergertme/111226036280440360

I also have an old Thinkpad T400 which I'm sometimes using to test stuff and there kgx got noticeable slower after the GTK4 port as it basically only added overhead without making use of the advantages of a GL renderer. These improvements should easily turn things around, possibly making it faster than it ever was with software rendering.

[EphemeralEft]

Someone please optimize FBCon 😢

[MrCooper]

Hi Christian, Michel Dänzer here.

But to get things really low, you'd want to get rid of any delay introduced by the compositor or GTK's event controllers.

FWIW, mutter can easily achieve single-digit milliseconds latency between when it processes an input event and when the resulting frame starts being scanned out. Clients incur some latency of their own though.

One recent discovery for mutter was that for sporadic updates such as in response to key events (as opposed to the steady state where a new frame is produced for every display refresh cycle), starting on the next frame ASAP after the event results in the lowest possible minimum and average latency. See my mutter!3174 which was merged for mutter 45.1. Might be worth checking if GTK does this or if it always waits for some time before starting on the next frame.

[mos87]

If I do something in GNOME, I rather just fire up plain, old xterm than touch that GNOME Terminal-thing. It's just so god damn slow that I rather deal with xterm's deficiencies than use GNOME Terminal.

Even when being super slow is a known (and acknowledged by its maintainer) xterm's deficiency...

[elduderino]

One recent discovery for mutter was that for sporadic updates such as in response to key events (as opposed to the steady state where a new frame is produced for every display refresh cycle), starting on the next frame ASAP after the event results in the lowest possible minimum and average latency. See my mutter!3174 which was merged for mutter 45.1. Might be worth checking if GTK does this or if it always waits for some time before starting on the next frame.

Very cool stuff! Yeah we should probably spend some time redoing the frame clock in GTK anyway.