LibreOffice Git Lands Its Skia Drawing Code - Leading To Vulkan-Accelerated Office Suite

[phoronix]

Phoronix: LibreOffice Git Lands Its Skia Drawing Code - Leading To Vulkan-Accelerated Office Suite

With LibreOffice 6.4 branched ahead of its release next year, feature development is open on what will be the next follow-on release for later in 2020. And this week one big underlying code change was merged... Using Skia for drawing the interface in an effort to ultimately replace the Cairo usage...

http://www.phoronix.com/scan.php?page=news_item&px=LibreOffice-Skia-Landed

[coder]

Hmmm... figures. Just before C++ is set to adopt Cairo as a standard GUI library, people are already moving away from it.

I always thought GUIs were a bridge too far.

[RahulSundaram]

Hmmm... figures. Just before C++ is set to adopt Cairo as a standard GUI library, people are already moving away from it.

I always thought GUIs were a bridge too far.

Cairo is written in C. The C++ library is going to be based on Cairo but not the implementation directly. So moving away from Cairo doesn't affect that process. The cairo api is still a solid one

[Elv13]

(One of AwesomeWM dev here, we use Cairo)

Cairo/QPainter are dead ends. They are very good at what they do, but the `context` object and the way it works dooms the entire API to be CPU bound. The OpenGL backends for QPainter and Cairo are much slower than the raster ones. That's because if all the round trips between the CPU and GPU which end up having an overhead larger than the gains. For pure raster CPU bound graphics, they are as good as they can get. The problem is that HiDPI screens have 4 time the number of pixels to draw. At that point the CPU becomes too slow to get a good frame rate.

Skia, on the other hand, is hopeless for different reasons. I don't think LibreOffice will love it long term. The API is not stable and it uses an insane build system that make it nearly impossible to integrate into Linux distribution. It is very fast, but the maintenance cost is unacceptable. They had some CMake support at some point, but they dropped it (and it was always broken). As long as they don't semver properly and **support** CMake/Meson as an alternative build system, it isn't going to be adopted by OpenSource projects. At least not without having their own internal forks (like Chrome and like Firefox used to have).

[R41N3R]

Good news, moving to Skia and especially Vulkan seems like a nice step!

[polarathene]

The OpenGL backends for QPainter and Cairo are much slower than the raster ones. That's because if all the round trips between the CPU and GPU which end up having an overhead larger than the gains.

Is it not able to combine all the image/texture resources into a single large one? That's generally how I've approached UI with GPU, a texture atlas/spritesheet for all the small graphics is much better performance reducing context switches iirc(haven't done such in almost a decade).

[Elv13]

Is it not able to combine all the image/texture resources into a single large one? That's generally how I've approached UI with GPU, a texture atlas/spritesheet for all the small graphics is much better performance reducing context switches iirc(haven't done such in almost a decade).

I am not the ultimate expert on this topic, but what would be the point of that? If you create larger textures in the CPU, then upload them to the GPU each time they change, then in you have to regenerate them in the CPU each time they change. In the end this is exactly what raster backends + WM compositing does. So you gain nothing at all. That solves none of the problem where GPU is better (HiDPI, animations, power efficiency on mobile SoC, VR, matrix transformations, shaders)

I previously was referring to building paths/gradients using Cairo/QPainter, then upload them to the GPU. If the CPU has to build the path, then upload it to the GPU for each for path for each frame, then you end up with better performance by using raster textures.

Qt5/GTK4 are much smarter and build a scene graph in the main memory and use a pipeline to upload changes only when necessary.

[Volta]

Qt5/GTK4 are much smarter and build a scene graph in the main memory and use a pipeline to upload changes only when necessary.

It looks there's a large gap between those two. Qt5 is available since long time, but gtk4 isn even released.

[polarathene]

I am not the ultimate expert on this topic, but what would be the point of that?
...
So you gain nothing at all. That solves none of the problem where GPU is better (HiDPI, animations, power efficiency on mobile SoC, VR, matrix transformations, shaders)

A texture atlas has all the different states of your graphics/UI elements. So a button could be the normal state, the hover state and pressed down state. For a 9-slice texture, which as the name implies divides a graphic into 9 slices(subtextures) you have a single texture to draw out panels/windows(not really the kind on desktops) with. For bitmap fonts especially, having a separate texture for every character vs all of them on the same texture packed together makes a notable difference in performance.

Take several paragraphs of text, and reference each individual texture for the glyphs used, that's a lot of context switches(I think that was the term, I haven't done this since 2013), whereas with the single texture covering all the glyphs, which is what you'll see pretty much everywhere that bitmap fonts via GPU are done as, you can reference all your glyphs and paint them to the viewport texture to render the content laid out. It's much more efficient, memory wise too if the system only works with power of two textures. I wrote a component specifically to handle paragraphs of text back when Flash was in demand, on a Nexus 7 tablet the regular text component had really bad performance, and the basic GPU UI component didn't handle scrolling too well iirc but was otherwise much better than the same font without the GPU approach, so I used a virtual list.

If the CPU has to build the path, then upload it to the GPU for each for path for each frame, then you end up with better performance by using raster textures.

Yes, dynamic textures like that aren't ideal to be frequently creating and discarding afaik. Most of the hit is during the texture upload to GPU, or at least was when I worked with it.

There are some GPU approaches though that take the path and convert it into a flat 2D mesh(triangles), using this geometry with solid colour or gradient textures to do this more efficiently. That way textures don't have to be uploaded at such a high frequency. Rust has some fairly good quality packages for doing just this I think, might have been called Lyon?

[ssokolow]

It looks there's a large gap between those two. Qt5 is available since long time, but gtk4 isn even released.

That's a bit of an understatement, given that they're gearing up for Qt 6 and, back in the days of Qt 4, GTK+ fans were lamenting that Qt beat them to offering support for doing 3D transforms on widgets and also transforming input events to deliver them properly.