GPU acceleration?

[Izaic]

I assume convergence is not within the scope of this application, so this question will be moot...

On low powered arm devices such as the Pinephone using the GPU to offload rendering of applications can greatly reduce resource usage and increase power efficiency. Is GPU acceleration something that is possible with this toolkit in the future?

[thesquash]

Yeah, I think it's possible in the future. It's just I can't really use GTK's approach to GPU acceleration, for various reasons. To the best of my understanding:

GTK+ 2 (ever since version 2.8) uses Cairo for almost all rendering of widgets. This means that XRender, an extension to the X Protocol to allow (very limited) GPU rendering, is used by GTK+ 2 when the extension is available (it usually is these days). This was the first time GTK really included any GPU acceleration code (albeit it is rather indirect a method). The main problem is that GTK+ 2 also uses "self-copy" operations to scroll text and other content onscreen: Self-copy operations instruct the GPU to copy a section of pixel data already onscreen to a destination location somewhere else on the screen. Unfortunately, these operations have a tendency to slow down more recent GPUs and make them a little less efficient than they could be.

GTK+ 3, as usual, made things even worse: Now whenever you scroll a single pixel, the entire scrolled area must be totally re-rendered. And guess what -- re-rendering is even slower than self-copy operations and apparently breaks the "rendering pipeline" even more than self-copy operations -- maybe it actually works fine on stuff like Nvidia GPUs, I haven't tried. But it sure is slow and flickery as heck on Intel integrated graphics, old or new. So redrawing everything is not going to happen in STLWRT anytime soon.

And then the situation is even worse on GTK+ 3 on Wayland: The entire screen image is drawn to a CPU-rendered offscreen buffer and then sent to the GPU to draw the contents of the buffer to the screen. Really terrible in terms of power consumption.

GTK 4 is a little better than GTK+ 3 in this regard, but not by much: Now GTK pretty much requires OpenGL or Vulkan access to the GPU, and does accelerate a few operations. However, the vast majority of drawing operations are actually done to a lot of really tiny offscreen CPU-rendered buffers, and then the offscreen buffers (textures) are overlapped on top of each other by the GPU. That's not how hardware acceleration should work! The GPU should do as much drawing as possible!

Seriously, maybe that works well enough, but I'm not yet sure how the GTK Team can say that GTK now takes full advantage of your GPU hardware. It looks like it takes some advantage of GPU hardware.

---

So in other words, I don't think there's a technical reason why we can't have good hardware acceleration in STLWRT, but I don't yet see how to do it exactly.

[stuaxo]

It's a shame they are talking about removing opengl support from Cairo as that may have helped a little.

[Dadoum]

Maybe you could wrap Cairo around vkvg (a library with the same api, but rendering with vulkan) ?