GNOME's GTK Vulkan Renderer Faster Than OpenGL, Now Working On Windows

[iznogood]

ebassi if I remember correctly making GTK use Cairo for rendering was one of the biggest milestones and maybe the main reason for the version change of gtk+.

So now you say that you need to remove Cairo for gl or Vulcan? But Cairo is a vector rendering library providing a very rich API for drawing.
How are you planning to replace that using a more low level API such as GL or Vulkan? How about the GL backend of Cairo? And what about the platforms with bad GL performance and no Vulkan support? Are you dropping support for older systems?

[ldo17]

We need to disentagle GTK+ from Cairo because Cairo on a CPU won't ever get any faster at rendering than a GPU. We've essentially reached peak Cairo performance for what we do with a GUI toolkit, and it's clearly not enough.

Why do we need more and more complex rendering for GUI toolkits, exactly? I can understand all the gradients and drop shadows and faux-3D effects taking rendering time, but isn’t the current fashion to move away from that, to a more flat look?

[ssokolow]

Why do we need more and more complex rendering for GUI toolkits, exactly? I can understand all the gradients and drop shadows and faux-3D effects taking rendering time, but isn’t the current fashion to move away from that, to a more flat look?

A more flat look with animated fades and slides and other things which can perform much better if you upload the textures to the GPU once and then ask it to twiddle the positions and opacities.

[hansg]

We need to disentagle GTK+ from Cairo because Cairo on a CPU won't ever get any faster at rendering than a GPU. We've essentially reached peak Cairo performance for what we do with a GUI toolkit, and it's clearly not enough.

Cairo has a rich set of primitives that allows you to draw all kinds of interesting-looking shapes. Internally, it will redirect each drawing command into either a 'native' representation (for something like PDF or SVG), or it will generate a set of trapezoids that it will then proceed to combine with each other to form the final image.

A GPU-based solution can possibly accelerate that last stage (the trapezoids), but I cannot see it replacing the first stage (trapezoid generation). It's just not the kind of process that lends itself well to implementation on a GPU. And if it replaces only trapezoid rendering, it shouldn't be implemented as a replacement for Cairo, but as a render module for Cairo - thus also keeping the interface on the application side stable.

Also, having looked into what Cairo actually does, I'm not convinced that we have reached peak Cairo performance. Just drawing a simple line using Cairo is incredibly complex! This is not just a Bresenham algorithm and filling some pixels, it is a rather complex algorithm that will do numerous resource allocations, prepare buffers, deal with threading issues, etc. For each character being drawn, several mutexes will be set. Surely it can be made to go faster.

[Guest]

According to https://cgit.freedesktop.org/cairo/ , cairo doesn't have many maintainers anymore to begin with. Cairo is however "stable".
I also remember it took a while to reach the same performance in gtk2 with cairo as pre-cairo gtk+.

It hope gtk4 is as fast as gtk3 on desktops but I am assuming that is the plan.

[ebassi]

ebassi if I remember correctly making GTK use Cairo for rendering was one of the biggest milestones and maybe the main reason for the version change of gtk+.

So now you say that you need to remove Cairo for gl or Vulcan? But Cairo is a vector rendering library providing a very rich API for drawing.
How are you planning to replace that using a more low level API such as GL or Vulkan? How about the GL backend of Cairo? And what about the platforms with bad GL performance and no Vulkan support? Are you dropping support for older systems?

We're not going to remove Cairo altogether. Widgets will still be able to use Cairo for rendering 2D content, and you're still going to use Cairo to handle SVG or printing surfaces. We're trying, on the other hand, to remove all the internal uses of Cairo for rendering widgets.

The reason why Cairo was integrated inside GTK+ — something that happened *after* 2.0 was released — was to have a drawing API that was better than something that emulated Xlib calls everywhere, which is what GTK+ used up until 2.8 (2005). While Cairo created "perfect" results, it was also slow as hell, and it took several years to get somewhat faster. The idea of using trapezoids everywhere for tesselation was also a design mistake that cannot be rectified (GPUs simply do not work that way). Sadly, Cairo is barely used outside of GTK+ itself, these days, and it's also barely maintained. Additionally, its implementation and API makes it very poorly suited for acceleration using OpenGL or OpenGL ES. Finally, things that theme designers and users expect — like shadows or blur, or filter effects — are impressively slow in Cairo, whereas they can get really fast on your GPU, if you start using the appropriate API.

If you followed the field in the past 10 years you'll have to come to the conclusion that there's only one supported cross-platform rendering API available (OpenGL); now we kind of have Vulkan, as the "next OpenGL", but both GL and Vulkan essentially "collapse" into the same drawing model, with Vulkan being a more efficient implementation. Anything released in the last 10 years has enough juice to run your desktop and your applications, and potentially fall back to the CPU for some stuff. If you want to target something older than that, GTK+ 3.x is still available, and it'll be available for the next 5+ years at least, just like GTK+ 2.x is still available 5+ years after GTK+ 3.0 was released.

[ebassi]

Cairo has a rich set of primitives that allows you to draw all kinds of interesting-looking shapes. Internally, it will redirect each drawing command into either a 'native' representation (for something like PDF or SVG), or it will generate a set of trapezoids that it will then proceed to combine with each other to form the final image.

I'm not sure if you're trying to tell me how Cairo works…

A GPU-based solution can possibly accelerate that last stage (the trapezoids), but I cannot see it replacing the first stage (trapezoid generation). It's just not the kind of process that lends itself well to implementation on a GPU. And if it replaces only trapezoid rendering, it shouldn't be implemented as a replacement for Cairo, but as a render module for Cairo - thus also keeping the interface on the application side stable.

The whole idea of using trapezoids is broken to begin with: GPUs do not use trapezoids, and trapezoids end up costing a ton of bandwidth when submitting the vertices. Additionally, typical GUI rendering will end up with simple shapes — rectangles, rounded rectangles, triangles — that can be easily pushed to the GPU, and in many cases you can even do rounded corners on the GPU itself via shaders. Of course, Cairo does not have a "rounded rectangle" primitive, but even admitting it could be added, with a shortcut implementation on GL, the toolkit above Cairo is always going to have better information about the whole state than Cairo does.

GTK+ implements the CSS state system, which does not match the Cairo one; this means that every time we enter Cairo we need to set up a ton of state that gets completely ignored by Cairo itself. The only way to make this better would be to have Cairo implement the CSS rendering state, which would break the API. Mozilla attempted this, and they gave up — also because Cairo is basically unmaintained, these days.

Also, having looked into what Cairo actually does, I'm not convinced that we have reached peak Cairo performance. Just drawing a simple line using Cairo is incredibly complex! This is not just a Bresenham algorithm and filling some pixels, it is a rather complex algorithm that will do numerous resource allocations, prepare buffers, deal with threading issues, etc. For each character being drawn, several mutexes will be set. Surely it can be made to go faster.

Okay, let me correct my assertion, then: given the current maintenance state of Cairo; the constraints imposed by its design; and the likelihood of an API-breaking set of changes necessary to improve performance, then we have reached peak Cairo usage. Anything better will require changing Cairo so drastically that it'll become something else entirely. At this point, I'd rather people used Cairo for custom 2D rendering and for SVG/PDF surfaces — but in terms of GUI rendering, it's done.

[ldo17]

Sadly, Cairo is barely used outside of GTK+ itself, these days...

I have used it a lot.

Is there something else I should be using instead?

[hansg]

I have used it a lot.

Is there something else I should be using instead?

I use it a lot too, and I have the same question. Is there an alternative that will give me:
- Perfect anti-aliased drawing.
- PDF and printed output using the same set of drawing primitives (i.e. not writing the code three times for screen, printer, and PDF!).
- Works on Windows, Linux, and MacOS.

Because right now I cannot think of any library that meets that goal. OpenGL and Vulkan were mentioned, but:
- Availability depends on hardware and drivers.
- No output to PDF or printer.
- ...yes, they are about graphics. But you would have to build every drawing primitive yourself, from scratch, in the most convoluted way imaginable. Quite frankly, I can spend my time more productively than that.

[RoboticRetina]

...

embassi, is there any chance for a game engine to use gtk to save time when implementing a GUI library? It might be utterly stupid, I don't know. Obviously you would want to implement the rendering yourself and skip styling (I guess). The thing is these toolkits need quiet a lot of features, as evidenced by UE4 and other engines being able to use their toolkit in their editors which are straight up desktop gui applications.

I've also thought that far into the future you might have a 'game' where there's a computer in-game and at that point you might want every feature of a modern toolkit just to create some applications for that virtual computer.