What is the future of the Skia backend?

[mccakit]

Currently, using the skia backend is not a very nice experience, there are tons of bugs in compiling skia itself, there are bugs when generating bindings and there are bugs in cross compilation in general.

Now, since skia is the most performant cross platform 2D renderer, I would like to use it.
However, I can't use prebuilt binaries that rust-skia uses because I use the llvm stack for all desktop + android development, this means I compile libc++, libunwind, libc++abi and compiler-rt, and also build rustc and all its standard llibrary distributions with that as well.

Any binary build would link to stuff I don't want, MSVC STL for windows, gcc_s and stdc++ for linux etc.

So, will the library prefer femtovg, or will rust-skia crate be actually useable without massive headaches?

[tronical]

So, will the library prefer femtovg, or will rust-skia crate be actually useable without massive headaches?

I'm not sure how to best answer this question.

This is the way that I see the role of skia:

• Google is maintaining Skia and they make certain choices about the compilers and platforms they support.
• Armin is doing a fantastic job at keeping the Rust skia bindings up-to-date and providing binaries for the most common users.
• We build on both to offer our users the option of Slint rendering with Skia. Ideally users can just use the Skia binaries from the Rust bindings project.

Cross-compiling the Rust skia bindings can be tricky, with the need to specify the sys root, the correct clang target flags for the skia build, the same (sys root and target) for lib clang when generating the bindings as well as for compiling them (bindings.cpp, etc.). Any mistake results in typically obscure error messages.

We welcome contributions to Slint's documentation, and I'd also be happy to help review and guide towards documentation improvements in the rust skia bindings to cover more "corner" cases. Perhaps there are even ways of simplifying the build process to require less environment variables, etc.

With regards the femtovg: I don't foresee any fundamental changes to the implementation, so I think it will continue to be easy to compile, but it will also continue to come with some bugs and performance limitations. The main change that I'd like to do soon is to switch the default from OpenGL (glutin) to use wgpu. That might might affect cross-compilation complexity, although I haven't yet heard about any concrete issues here (in contrary).

Going forward, I'd also like to add vello as a supported renderer in Slint. On my laptop I've got some scaffolding to do so, but it's a bit of work to get that the renderer implemented, although it's now easier than ever due to our switch to parley.

[mccakit]

How about not using that crate at all?
It is very evident that calling gn inside cargo is bad, users should build skia with gn seperately first.
However the C++ binding generation is terrible, and skia itself needs patches to build against mingw targets.

So, why don't you guys fork skia add mingw support and fix msvc cross builds, and use the experimental C api to generate the rust bindings?
Skia will outperform any 2D renderer by a huge margin anyway. If I read correctly before it is like %50 faster than cairo and the likes.

Sure it will be a pain till skia C API becomes stable, but I believe it will be worth it.

Just my idea though, I really do not know the customer base you guys are dealing with, this is just my view as some guy who wants to write cross platform applications with all the niceties of qml and not a lot of the drawbacks

[mccakit]

C API example:
https://chromium.googlesource.com/skia/+/master/experimental/c-api-example/skia-c-example.c
My Skia fork that builds with vulkan and d3d support against mingw-llvm sysroot
https://github.com/mccakit/skia

[tronical]

So, why don't you guys fork skia add mingw support and fix msvc cross builds, and use the experimental C api to generate the rust bindings?

Maintaining a new fork, creating new bindings, and re-writing our existing renderer to use that API is an investment that is difficult to justify, in light of the the vast majority of our users finding the existing skia binaries working well for them.

That said, if somebody would like to do that and contribute a new renderer to Slint that uses such a few and API, I'd be happy to help review and integrate.