Progress on moving the background rendering fully to the GPU

[sirdoombox]

I've had some free time recently so I re-investigated the possibility of moving the background renderer fully onto the GPU to eliminate a source of performance drag.

Initially I got it running with OpenGL but it was exceptionally awkward to work with, so I moved onto Skia's rendering pipeline and got it running with not too much work. Currently the major downside is the Skia shader language SkSL which is quite limited in it's current form, thanks to Avalonia running SkiaSharp which itself runs a fairly old version of Skia at this point. This limitation mainly manifests itself in missing functions like mod, step and smoothstep (among others). It does make translating GLSL shaders a bit of a headache but it's feasible.

I've included 4 default shaders written in sksl - including the empty one which is simply called "flat" for people who don't want a flashy background. I'm not a shader wizard nor am I particularly artistically inclined so I (fairly heavily) adapted some ShaderToy shaders.

Here is a video of it running with the 4 shaders on a loop - I've turned the animation speed up so it's more visible for this demo:
https://dl.dropboxusercontent.com/scl/fi/okmadh8foq0bb53oo33z7/SukiUI.Demo_2024-06-19_10-03-58.webm?rlkey=62tolbunxnhzswtf8k333vz83&dl=0

I haven't been able to benchmark it but it's running at the native framerate of the application very, very smoothly with no noticeable performance impact.

The only thing I'm struggling with at the moment is rewriting the API for the background so it's a little nicer to work with. I'd ideally like to include it in SukiTheme but that class is already getting exceptionally heavy and giving it even more responsibility seems like a mistake. An alternative would be a SukiBackground static class which would act as the singleton in charge of everything. I hate singletons generally but it seems like the cleanest way to approach this global & local state problem.

Thought I'd give a quick pros/cons list for this feature overall:

Pros:

• Significantly more performant, taking advantage of hardware acceleration.
• Ability to render far more complex effects and animations.
• Opportunity to rewrite the underlying API for backgrounds.
• Far easier for devs to customise, shaders are relatively simple compared to the existing approach of manipulating a raw locked bitmap and all the unsafe code that comes with it - though if you're a C# GUI dev you might be unfamiliar with shaders.

Cons:

• Represents another breaking change, even if the API changes are kept to a minimum.
• Unable to perfectly recreate the existing background renderer's appearance.
• Avalonia's current version of SkiaSharp and therefore Skia has a more limited subset of SkSL features with some key basic functions missing.
• Passing data to the shader is currently fixed to what we decide should be available, though it is possible to expand this with some additional code, the result would be a fairly complex API.

I've completed the majority of the work needed to get everything running and really the only thing is getting the go-ahead to get this properly implemented and to what extent I should change the API around backgrounds.

[sirdoombox]

vec4 main(vec2 fragCoord) {
    vec3 col = mix(iPrimary, iAccent, sin(iTime));
    return vec4(col, 1.0);
}

thought I'd include a simple example of a shader written in SkSL if you're curious, this one lerps between the current primary and accent colors using the sine of the time, the variables prefixed with i are uniforms that are passed into the shader from C#. Currently the ones that I've made available to use are iTime which is just the time in seconds (this can be paused/stopped to control animation), iResolution which just represents the bounds of the background in pixels and 3 vec3 representing the colors iPrimary, iAccent and iBase which is white/black depending on the currently active base theme. You don't (and in fact shouldn't) write this into your shader file/string as I've set it up to inject those when the shader is loaded.

vec4 main(vec2 fragCoord) is the entry point for an SkSL fragment shader and the parameter represents the position of the particular pixel being rendered in pixels.

You can normalise this to a uv with vec2 uv = fragCoord / iResolution.xy; which causes your effect to scale properly with window size.