I 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.
nialv7 325 days ago [-]
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.
bjoli 325 days ago [-]
My main screen does not have VRR. It runs at 60hz.
worthless-trash 325 days ago [-]
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.
bjoli 325 days ago [-]
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).
purpleidea 325 days ago [-]
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 ???
epse 325 days ago [-]
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
mort96 325 days ago [-]
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?
sureglymop 325 days ago [-]
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.
immibis 325 days ago [-]
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.
Jotalea 325 days ago [-]
Ohh, so that was the image I saw there. Good to know.
lawik 325 days ago [-]
But can we Gilette this? Quadruple buffering? 24 buffers for the smoothest display?
mort96 325 days ago [-]
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.
maggit 325 days ago [-]
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.
rolandog 325 days ago [-]
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.
jhoechtl 325 days ago [-]
That sounds like a great visible improvement. Gnome is polished WM.
IIRC, KDE has had triple buffering for quite a while now. GNOME is playing catchup here.
konart 325 days ago [-]
>comparable
KDE is way ahead in (almost) all departments these days.
GuestFAUniverse 325 days ago [-]
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!
konart 325 days ago [-]
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.
mnahkies 325 days ago [-]
Anyone know if this is too late to make the cut for Fedora 42? (beta was announced this week)
microtonal 325 days ago [-]
The changes seem to be in the RC branch from GNOME 48:
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.
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).
Trying to look at the source... Is the whole thing less than ~1000 LOC ???
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.
Kudo's to Daniel van Vugt and all the testers that pitched in time and effort.
Does KDE/Plasma offer sthg. comparable?
[0] https://kde.org/announcements/plasma/6/6.0.90/
KDE is way ahead in (almost) all departments these days.
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!
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.
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?