Custom wgsl fragment shaders for the femtovg+wgpu backend

[expenses]

Requires femtovg/femtovg#263.

Tested with the following:

export component App inherits Window {
    preferred-width: 700px;
    preferred-height: 500px;
    Rectangle {
        width: 50%;
        height: 50%;
        background: fragment_shader(
"@fragment fn fs_main(@builtin(position) position: vec4<f32>) -> @location(0) vec4<f32> {return vec4<f32>(position.xy/1000.0,1,1);}"
        );
    }
}

It's a little tricky to use currently given that multiline strings aren't supported.

[expenses]

I had to add a `@include_string` macro but now you can do tons of stuff with them

[tronical]

Very nice to see that this is not very intrusive and quite feasible.

I think we may need to sit down and discuss with Nigel what the API really should look like. I have the feeling that it would be really good to be able to specify uniforms as Slint properties, and for that an element style API might be more suitable than a brush.

I also have the feeling that we may indeed want to focus primarily on the shaders being separate files, so an include_string or @fragment-shader() taking a file path always. That way users can benefit from WGSL syntax highlighting and completion in their IDE. Might seem overkill if your shader is just a one-liner, but I don't think that's the common case :)

Implementation wise, I have the feeling that since we'll need to implement this for other renderers like Skia or Vello in the future, we may need to have a generic implementation that uses wgpu and produces a texture, and then renderers (Skia, Vello, etc.) just blit that texture. For that we have import logic, and we just can't feed WGSL into Skia or Vello. But I might be missing something, so I'm curious what your thoughts are :)

[tronical]

(FWIW, I suggest to create a sub-task of #612 and we continue to discuss spec and design there)

[expenses]

@tronical will reply to the rest of this in a bit, but for now here's the @include_string implementation I got AI to bash out: master...expenses:slint:include-string-macro. Could potentially clean that up and merge it on it's own (might be valuable for large text blocks etc).

[tronical]

@tronical will reply to the rest of this in a bit, but for now here's the @include_string implementation I got AI to bash out: master...expenses:slint:include-string-macro. Could potentially clean that up and merge it on it's own (might be valuable for large text blocks etc).

I think @include-string() would be a useful function to have in the language. I will not be the sole gatekeeper for the feature, but I'll vote in favour.