SkSVGDOM bindings

[lol768]

Is your feature request related to a problem?

Skia's own frontend support for the SVG format is no longer experimental. Please expose an API around SkSVGDOM::Builder() with the ability to load SVG from file/string and render to a canvas.

Describe the solution you would like

For "inspiration", rust-skia re-exports via a C interface:

extern "C" SkSVGDOM* C_SkSVGDOM_MakeFromStream(SkStream& stream, loadSkData loadCb, loadSkTypeface loadTfCb, void* loadContext) {
    auto provider = sk_make_sp<ImageResourceProvider>(loadCb, loadTfCb, loadContext);
    auto builder = SkSVGDOM::Builder();
    builder.setResourceProvider(provider);
    return builder.make(stream).release();
}

and then exposes in its crate.

SkiaSharp should do the same.

Describe alternatives you have considered

Svg.Skia (which is based on SVG.Net). For reasons I don't fully understand, I found this to generate very large, inefficient PDFs (which used hundreds of /Patterns and produced PDF files hundreds of times larger than required) when importing a specific SVG to an SkPicture and then rendering to a PDF canvas. Generally I would expect the built-in native code in C++ to be a bit more performant too.

When I tried using the native C++ SkSVGCanvas stuff myself, the commands generated in the SkPicture were much more sensible.

Additional context

No response

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[HinTak]

FWIW, skia-python had SkSVGDOM::MakeFromStream 4 years ago, in m87, https://github.com/kyamagu/skia-python/blob/e0b030c14e33f70880cfcc502eaeed898a77fc3c/src/skia/SVGDOM.cpp#L13 before it became non-experimental in m88.

[fcallejon]

Hi @mattleibow is this branch supposed to cover this feature ? If anyone can guide me I can try to add SkSVGDOM.

[HinTak]

2017 sounds really old.

[HinTak]

Argh, the svgdom code was based on m57. Skia itself is m131 now... you need m10x at least for some of this.

[HinTak]

Btw, it may not be default on yet, you need skia_enable_svg=true passed to --args"..." of gn gen when building skia.

[HinTak]

While it was no longer experimental since m88, it is still optional as far as I know.

[mattleibow]

One downside of SVG support is that it pulls in the shaper, which pulls in the harfbuzz and unicode modules. This might make the small API ballon significantly. I am not sure we can add this until I figure out a way to make the modules be optional dependencies that can be included.

In addition to size, if there is a bug in skia's SVG, it will take a long time for that bug fix to reach us as I only update skia once a year or less. We may just need to actually get SVG.NET to be better nad faster - and then also Svg.Skia. If we fix that, we fix the entire community. Adding SVG to skia will make it bigger and may not have all the features yet either.

Maybe we can open an issue with the problems you are seeing on the Svg.Skia repo and then we can work to fix them there. I am not sure how modern the codebase is. It may have just been ported but not actually taking up the Spans and other new .NET features.

[HinTak]

As for harfbuzz / unicode, you'd want that for skparagraph and skottie, eventually.

[mattleibow]

That too is not something that I think we will add. For text, we have RichTextKit and we have a separate HarfBuzzSharp binding in this repo.

I see we do have a Skittie binding, so not sure what is included. Maybe some no-op shaper.

Maybe we can do the SVG and see what the resulting size is? Not sure if you would like to have a go at seeing what would happen. This PR is for skottie, so you could have a look at the native side and check the size: https://github.com/mono/SkiaSharp/pull/1987

[lol768]

Thanks for your comments @mattleibow

One downside of SVG support is that it pulls in the shaper, which pulls in the harfbuzz and unicode modules. This might make the small API ballon significantly. I am not sure we can add this until I figure out a way to make the modules be optional dependencies that can be included.

This is life really, isn't it? I agree that some way of making this be optional for folks who don't want/need proper text support might be prudent if it really does significantly impact the size, but if you want to do anything beyond the basics with rendering SVGs then you need to be able to render text and to be blunt you simply can't do this properly without harfbuzz. I would try and take inspiration from what other language bindings like skia-python and rust-skia are doing here.

In addition to size, if there is a bug in skia's SVG, it will take a long time for that bug fix to reach us as I only update skia once a year or less

You could make this argument about any functionality in Skia really though, couldn't you? I would love to see more frequent Skia updates, but I appreciate that's a very non-trivial undertaking and to be clear, I'm very grateful for the work you do currently. Even JetBrains struggle to do more than 2 Skia updates a year for their Compose stuff.

If we fix that, we fix the entire community. Adding SVG to skia will make it bigger and may not have all the features yet either.

The only thing I'd note here is that, whilst I think a pure .NET SVG implementation is nice and you're right about improving the ecosystem here being a good thing, the SkSVGDOM APIs benefit from being actively maintained by Google and wide adoption (e.g. JetBrains' Compose Multiplatform) elsewhere. However: I don't have a good enough understanding of how mature and comprehensive SkSVGDOM in latest Skia actually is to be honest, I haven't tested it extensively enough.

I suspect some of my historical complaints with SVG.NET/Svg.Skia are actually complaints with the Skia PDF backend.