New renderers for GTK – GTK Improvement Weblog

2024-01-28 21:24:10

Just lately, GTK gained not one, however two new renderers: one for GL and one for Vulkan.

Since naming is difficult, we reused current names and known as them “ngl” and “vulkan”. They’re constructed from the identical sources, due to this fact we additionally name them “unified” renderers.

However what’s thrilling about them?

A single supply

As talked about already, the 2 renderers are constructed from the identical supply. It’s modeled to observe Vulkan apis, with some abstractions to cowl the variations between Vulkan and GL (extra particularly, GL 3.3+ and GLES 3.0+). This lets us share a lot of the infrastructure for strolling the scene graph, sustaining transforms and different state, caching textures and glyphs, and can make it simpler to maintain each renderers up-to-date and on-par.

May this unified strategy be prolonged additional, to cowl a Metallic-based renderer on macOS or a DirectX-based one on Home windows? Probably. The benefit of the Vulkan/GL mixture is that they share mainly the identical shader language (GLSL, with some variations). That isn’t the case for Metallic or DirectX. For these platforms, we both must duplicate the shaders or use a translation instrument like SPIRV-Cross.

If that’s the type of factor that excites you, assistance is welcome.

Implementation particulars

The previous GL renderer makes use of easy shaders for every rendernode sort and steadily resorts to offscreen rendering for extra complicated content material. The unified renderers have (extra succesful) per-node shaders too, however as an alternative of counting on offscreens, they can even use a fancy shader that interprets knowledge from a buffer. In recreation programming, this strategy is called a ubershader.

The unified renderer implementation is much less optimized than the previous GL renderer, and has been written with a deal with correctness and maintainability. As a consequence, it could actually deal with far more different rendernode bushes appropriately.

Right here is an harmless-looking instance:

repeat {
  bounds: 0 0 50 50;
  youngster: border {
    define: 0 0 4.3 4.3;
    widths: 1.3;
  }
}

gl (left) ngl (proper)

New capabilities

We wouldn’t have finished all this work, if there wasn’t some tangible profit. After all, there’s new options and capabilities. Lets have a look at some:

Antialiasing. An enormous downside with the previous GL renderer is that it’s going to simply lose high-quality particulars. If one thing is sufficiently small to fall between the boundaries of a single line of pixels, it is going to merely disappear. Particularly this will have an effect on underlines, akin to mnemonics. The unified renderers deal with such instances higher, by doing antialiasing. This helps not only for preserving high-quality element, but in addition prevents jagged outlines of primitives.

Fractional scaling. Antialiasing can be the idea that lets us deal with fractional scales correctly. In case your 1200 × 800 window is about to be scaled to 125 %, with the unified renderers, we are going to use a framebuffer of dimension 1500 × 1000 for it, as an alternative of letting the compositor downscale a 2400 × 1600 picture. A lot much less pixels, and a sharper picture.

Arbitrary gradients. The previous GL renderer handles linear, radial and conic gradients with as much as 6 shade stops. The unified renders enable an limitless variety of shade stops. The brand new renderers additionally apply antialiasing to gradients, so sharp edges could have easy traces.

A linear gradient with 64 shade stops

Dmabufs. As a short detour from the brand new renderers, we labored on dmabuf assist and graphics offloading last fall. The brand new renderers assist this and lengthen it to create dmabufs when requested to supply a texture through the render_texture api (at the moment, simply the Vulkan renderer).

Any sharp edges?

As is usually the case, with new capabilities comes the potential for brand spanking new gotchas. Listed below are some issues to pay attention to, as an app developer:

No extra glshader nodes. Sure, they made for some fancy demos for 4.0, however they’re very a lot tied to the previous GL renderer, since they make assumptions concerning the GLSL api uncovered by that renderer. Subsequently, the brand new renderers don’t assist them.

You’ve got been warned within the docs:

If there’s a downside, this operate returns FALSE and experiences an error. It is best to use this operate earlier than counting on the shader for rendering and use a fallback with a less complicated shader or with out shaders if it fails.

Fortunately, many makes use of of the glshader node are now not obligatory, since GTK has gained new options since 4.0, akin to masks nodes and assist for straight-alpha textures.

Fractional positions. The previous GL renderer is rounding issues, so you might get away with handing it fractional positions. The brand new renderers will place issues the place you inform it. This will generally have unintended consequences, so ought to be looking out and make it possible for your positions are the place they need to be.

Particularly, look out for out for cairo-style drawing the place you place traces at half-pixel positions in order that they fill out one row of pixels exactly.

Driver issues. The brand new renderers are utilizing graphics drivers in new and alternative ways, so there’s potential for triggering issues on that facet.

Please file issues you see towards GTK even when they seem like driver points, since it’s helpful for us to get an summary how properly (or badly) the brand new code works with the number of drivers and {hardware} on the market.

However is it sooner?

No, the brand new renderers aren’t sooner (but).

The previous GL renderer is closely optimized for pace. It additionally makes use of a lot less complicated shaders, and doesn’t do the maths that’s wanted for options akin to antialiasing. We wish to make the brand new renderers sooner finally, however the brand new options and correctness make them very thrilling, even earlier than we attain that purpose. All the GPU-based renderers are greater than quick sufficient to render todays GTK apps at 60 or 144 fps.

That being mentioned, the Vulkan renderer comes near matching and surpassing the previous GL renderer in some unscientific benchmarks. The brand new GL renderer is slower for some cause that we’ve not tracked down but.

New defaults

Within the just-released 4.13.6 snapshot, we’ve made the ngl renderer the brand new default. This can be a trial balloon — the renderers want wider testing with completely different apps too confirm that they’re prepared for manufacturing. If vital issues seem, we are able to revert again to the gl renderer for 4.14.

We determined not make the Vulkan renderer the default but, since it’s behind the GL renderers in a number of utility integration points: the webkit GTK4 port works with GL, not with Vulkan, and GtkGLArea and GtkMediaStream at the moment each produce GL textures that the Vulkan renderer can’t straight import. All of those points will hopefully be addressed within the not-too-distant future, after which we are going to revisit the default renderer determination.

In case you are utilizing GTK on very previous {hardware}, chances are you’ll be higher off with the previous GL renderer, because it makes fewer calls for on the GPU. You’ll be able to override the renderer choice utilizing the GSK_RENDERER setting variable: