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

• 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: #1987