Gnome / mutter triple buffering patch merged
gitlab.gnome.orgI wonder if this will also fix the problem i have with my mouse cursor only drawing at what seems like 24 fps. It is noticeably laggier than in KDE.
It has something to do with drawing, because over some surfaces it doesn't happen, but all gtk native apps exhibit it. This is a 7900x with an intel a750 graphics card. It should not happen.
Cursors are generally rendered with a different mechanism than the rest of the screen. What you are describing sounds a lot like a problem with VRR.
My main screen does not have VRR. It runs at 60hz.
As always, you should lodge a bug, there has been some improvements in mouse rendering about 3 months ago iirc, but I don't remember specific details.
There are already a couple of mutter bug reports regarding cursor stuttering. Mine is bound to be related to one of those.
Anyway, I realized I really don't like gnome. I used it for 13 months and installed all different extensions to deal with issues. Then I realized that this is just the mac os experience, and that I personally really don't like it. Now I am migrating to KDE, which takes 10 minutes to configure and can then be foegotten, and I wont get a lousy experience if any extensions are incompatible with the next update of gnome (which happened on every major update).
Sweet! I know this patch has been cooking for a while, gosh the gitlab page takes ages to even load...
Trying to look at the source... Is the whole thing less than ~1000 LOC ???
You probably got served an Anubis challenge first, doing some computations to block (LLM) scraper bots, which does slow down loading by a second or so
Speaking of, I don't mind that in principle, but why does it linger so long on the "Success" page? It adds a handful of milliseconds of page loading and 30ms of computation, and an eternity (~seconds) of just an unnecessary delay before even starting to load the site I actually wanna go to, whys that?
Makes the page entirely unreachable from within the Harmonic hacker news client on android... Good idea in practice but defeats the purpose if it blocks legitimate users.
It's not a good idea in practice precisely because it blocks legitimate users. As it always will. It's not possible to do this sort of thing without blocking legitimate users.
Ohh, so that was the image I saw there. Good to know.
But can we Gilette this? Quadruple buffering? 24 buffers for the smoothest display?
I believe 3 buffers is the minimum you need for the CPU and GPU to be able to work independently and never wait for each other. Sure, one could queue up a bunch of extra frames and you'd have more margin in case of a multiple frames long stutter (at the cost of a lot of input latency), but you're typically better served avoiding multiple frames long stutters if possible. Triple buffering is, I believe, more about squeezing out all the performance you can from the hardware, not about just queuing up some number of frames which happens to be 3.
Adding some detail to this: With three buffers, you have one front-buffer (what's currently visible on screen) and two back-buffers. Let's call them A, B and C, respectively. This lets you work on the next frame in, say, B, and when it's ready, you queue it up for presentation. At the right time, then, the roles of the buffers will be switched, making B the front-buffer and A a back-buffer.
The third buffer comes into play if you want to start working on the next frame _before_ the switch has occurred. So you start drawing in C, and if the right time should hit, the display system can still flip A and B. In this case, triple buffering gave you a head-start with drawing the frame in C.
Going further, if you complete the frame in C still before the A/B switch has happened, you queue up C as the next frame, instead of B. Then, you can start working on the next frame again in B. With this scheme, there is no sense in having more buffers than three.
Great news! It's fascinating to read all the effort very dedicated and talented people put into improving the software we love and use.
Kudo's to Daniel van Vugt and all the testers that pitched in time and effort.
That sounds like a great visible improvement. Gnome is polished WM.
Does KDE/Plasma offer sthg. comparable?
KDE rolled that out in June last year [0]
IIRC, KDE has had triple buffering for quite a while now. GNOME is playing catchup here.
>comparable
KDE is way ahead in (almost) all departments these days.
bwahahaha
Wishful thinking. I do 1st and 2nd level support on several hundred Linux desktops.
KDE isn't even close to Gnome when it comes to stability and Wayland support -- I mean: seriously? Wayland is a decade old.
And the last time I saw a stable KDE is two decades ago. I'm so annoyed by the crowd recommending it.
I'm tired of DrConqi leaving hundreds of useless systemd units behind and triggering countless alarms. Sucks, big time!
No idea about stability on that scale, I don't do support. On my local machine both behaved about the same in the past.
KDE however is way ahead in fractional scaling, buffering etc. Not sure how to measure Wayland support. Do tell though.
>I'm so annoyed by the crowd recommending it.
Well, Gnome's fault. I've been on team Gnome until they've ruined it after Gnome 2 is ended. Can't really use it with more than one monitor these days too.
Anyone know if this is too late to make the cut for Fedora 42? (beta was announced this week)
The changes seem to be in the RC branch from GNOME 48:
https://gitlab.gnome.org/GNOME/mutter/-/commits/48.rc?ref_ty...
So, unless they are disabled or backed out, seems they might land in Fedora 42?
It was merged Feb 14 2025. It'll be in GNOME 48 and Fedora 42. It's likely already in the Fedora beta branch.
I don't fully understand this, but it sounds like a nice optimization.