resvg VS iconvg

For example, when converting vector SVG images to raster PNG images with resvg, most of the time is spent compressing the PNG image. This is a lot of wasted work if we just want to read the image instead of transferring it over the network! The fast compression mode eliminates all this wasted work, resulting in huge performance and efficiency gains.

Just as a point of reference, I have a ~75KLOC project (includes dependencies) called resvg which takes just 4s in the debug mode and 8s in the release mode to build on M1 Pro.

resvg is very fast, although the performance depends on the exact SVG you feed it - sometimes faster than librsvg, sometimes slower (although librsvg is also written in Rust now, it does use unsafe while resvg doesn't)

So, all you gotta do is rewrite the parsers. Funny you mention librsvg because there is a library called resvg that has a thumbnailer implementation for Windows Explorer. https://github.com/RazrFalcon/resvg

A small nitpick as the resvg author: the repo located here https://github.com/RazrFalcon/resvg I'm not sure why the author linked some random, outdated fork. If you're trying to beat SVG, you should have done a better research.

But yes, SVG is extremely bloated and under-documented. Especially SVG 2. The core resvg codebase is close to 20 KLOC, while the whole package is like 50 KLOC.

On the other hand, resvg is an exception, because it doesn't rely on any system and/or 3rd party libraries. 95% of the code in the final binary was written by one person (me). Not because it was strictly required, but because it was fun. resvg is basically an epitome of RIIR.

>How much work would it be to port over the C# SVG→TinyVG converter to Rust based on resvg?

Probably a day, as long as you know Rust. I can take a look into it if you're interested. usvg (the SVG parser of resvg) is specifically designed to convert a real world SVG with all its quirks into a machine readable, minimal SVG/XML.

One thing to note is that usvg doesn't preserve text at the moment (will be converted into paths automatically) and Quadratic curves.

PS: I also have a longer, but still unfinished rant [0] over SVG complexity if you're interested.

[0] https://github.com/RazrFalcon/resvg/blob/master/docs/renderi...

As an example/proof, resvg contains close to 100KLOC (including all dependencies) and compiles in 13s on Apple M1 (clean release build).

The HN thread also mentions Lottie from AirBnB and IconVG from Not-an-official-Google-product.

IconVG author here. Happy to discuss.

Animation is issue #2 on https://github.com/google/iconvg and I have some ideas but no code yet. I'm also midway through changing the current "version 0" format into a "version 1" format, dropping things like the ArcTo op (inspired by SVG) precisely with one eye on (future) animation support. The ArcTo large-arc-flag, like any boolean-typed value, is impossible to interpolate smoothly.

https://github.com/google/iconvg/blob/main/spec/iconvg-spec.... also doesn't explain what relative cubeTo does, though from the context (2D vector graphics), “relative” must mean the co-ordinates are relative to the position of the cursor (as opposed to “absolute” which is relative to some fixed origin), and “cube” probably refers to cubic interpolation.