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.
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).
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.
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.
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.
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.