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]
Gnome / mutter triple buffering patch merged
11–20 of 27 posts
Re: Gnome / mutter triple buffering patch merged
#12Sweet! 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
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.
Re: Gnome / mutter triple buffering patch merged
#13Anyone know if this is too late to make the cut for Fedora 42? (beta was announced this week)
Re: Gnome / mutter triple buffering patch merged
#14But 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 squ…
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.
Re: Gnome / mutter triple buffering patch merged
#15Anyone 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?
Re: Gnome / mutter triple buffering patch merged
#16Anyone know if this is too late to make the cut for Fedora 42? (beta was announced this week)
It was merged Feb 14 2025. It'll be in GNOME 48 and Fedora 42. It's likely already in the Fedora beta branch.
Re: Gnome / mutter triple buffering patch merged
#17I 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.
Re: Gnome / mutter triple buffering patch merged
#18I 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.
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.
Re: Gnome / mutter triple buffering patch merged
#19I 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.
Re: Gnome / mutter triple buffering patch merged
#20Earlier quoted context omitted.
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
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.