Enable Skia for the live preview in VS code on macOS, Linux and Windows

[tronical]

Skia's rendering quality is better than FemtoVG.

The WASM build remains with FemtoVG (that's not just flipping a switch). The rest of our binaries are built with Qt support.

[tronical]

I can clean up the code a little by perhaps moving this into a variable of sorts, or perhaps the feature default should be changed?

But what do you think about this direction in general?

[hunger]

I am all for it, if it indeed looks better:-)

But I would suggest to change the defaults and build the exception with extra flags and not the normal case.

[ogoffart]

I don't think that's the right way to do it. We should not disable the other backend. And especially, we should not have a different default than the actual code. In other word, everything should have the same default.

[tronical]

I don't think that's the right way to do it. We should not disable the other backend.

Is there a benefit to shipping unused backend/rendering code in the binaries included in the .vsix file?

And especially, we should not have a different default than the actual code.

That's tricky though, as we don't know what the code default is. If Qt is available, it'll be Qt, otherwise it'll be femtovg. Unless one day the preview gets a "user interface" with a way of selecting the renderer in the same way that it can be selected at run-time by actual code.

In other word, everything should have the same default.

Okay, if everything means literally everything then we can't do this change, as we can't select Skia for the wasm build and thus can't make it the default.

Can you elaborate what's in "everything"?

[ogoffart]

Is there a benefit to shipping unused backend/rendering code in the binaries included in the .vsix file?

There is a config option to select the backend with vscode, so yes

Okay, if everything means literally everything then we can't do this change, as we can't select Skia for the wasm build and thus can't make it the default.

We can have different default feature for different architecture though.

Can you elaborate what's in "everything"?

I mean, skia should be the default if you do cargo build in your app, and should be the devault in the viewer, and the default when using C++

[tronical]

Okay, if everything means literally everything then we can't do this change, as we can't select Skia for the wasm build and thus can't make it the default.

We can have different default feature for different architecture though.

How is this possible?

[ogoffart]

We can have different default feature for different architecture though.

How is this possible?

in the backend-selector

[target.'cfg(not(target_arch = "wasm32"))'.dependencies]
i-slint-backend-winit = { feature="renderer-skia" }  

or something like that.

[tronical]

We can have different default feature for different architecture though. How is this possible?

in the backend-selector

[target.'cfg(not(target_arch = "wasm32"))'.dependencies]
i-slint-backend-winit = { feature="renderer-skia" }  

or something like that.

Right, but then I think it's not possible for users to opt out of this feature anymore, isn't it?

I.e. you can't do slint = { version = "0.3", default-features = false, features = ["compat-0-3-0", "renderer-winit-software"]. Well, you can, but you'll also get the skia renderer, which you don't get with 0.3.0.

[ogoffart]

Ah Right. We'll would neet to hack something using another level of indirection.

Or, since the skia backend anyway doesn't compile in wasm, we can make the feature a no_op in wasm by putting all the skia dependencies in [target.'cfg(not(target_arch = "wasm32"))'.dependencies].

[tronical]

Ok, agreed, this should be done in line with changing the default renderer for winit when Qt is not available. Separate PR.