Double and triple buffering are techniques in GPU rendering (also used in computing, up to double buffering only though as triple buffering is pointless when headless).

Without them, if you want to do some number crunching on your GPU and have your data on the host (“CPU”) memory, then you’d basically transfer a chunk of that data from the host to a buffer on the device (GPU) memory and then run your GPU algorithm on it. There’s one big issue here: during the memory transfer, your GPU is idle because you’re waiting for the copy to finish, so you’re wasting precious GPU compute.

So GPU programmers came up with a trick to try to reduce or even hide that latency: double buffering. As the name suggests, the idea is to have not just one but two buffers of the same size allocated on your GPU. Let’s call them buffer_0 and buffer_1. The idea is that if your algorithm is iterative, and you have a bunch of chunks on your host memory on which you want to apply that same GPU code, then you could for example at the first iteration take a chunk from host memory and send it to buffer_0, then run your GPU code asynchronously on that buffer. While it’s running, your CPU has the control back and it can do something else. Here you prepare immediately for the next iteration, you pick another chunk and send it asynchronously to buffer_1. When the previous asynchronous kernel run is finished, you rerun the same kernel but this time on buffer_1, again asynchronously. Then you copy, asynchronously again, another chunk from the host to buffer_0 this time and you keep swapping the buffers like this for the rest of your loop.

Now some GPU programmers don’t want to just compute stuff, they also might want to render stuff on the screen. So what happens when they try to copy from one of those buffers to the screen? It depends, if they copy in a synchronous way, we get the initial latency problem back. If they copy asynchronously, the host->GPU copy and/or the GPU kernel will keep overwriting buffers before they finish rendering on the screen, which will cause tearing.

So those programmers pushed the double buffering idea a bit further: just add an additional buffer to hide the latency from sending stuff to the screen, and that gives us triple buffering. You can guess how this one will work because it’s exactly the same principle.

GNOME devs need to touch grass and listen to the actual users.

I totally agree. However, interacting with any gnome devs is like pulling teeth. They keep making bad decisions to be ‘different’ and make their jobs easier, then when those decisions turn out to be bad they have to walk them back but never admit fault.

Being able to move the dock is fine example of this.

It’s like they want Apple’s lack of customization but can’t provide a competitive default (because they suck at their jobs.)

Gnome devs will never listen to criticism. Even if you do a MR it might get denied because it contraricts with the “Gnome way”. Just use KDE and live an happy life. KDE can be easily modified to look like Gnome and have all the QOLs you need.

That wouldn’t be the true gnome experience.

deleted by creator

There’s a Fedora copr with the triple buffering patches and it did improve the perceived smoothness of Gnome’s animations on my 8th gen Intel CPU.

It was especially noticeable if the system was limited in power because of running on battery.

Canonical have had it in Ubuntu for years, but it’s taken them a while to get it to a point where it could be upstreamed. That’s what this news is: that Canonical’s patch is finally all clear to be merged.