TinyVG: A challenger to the throne of vector graphics

Re:TinyVG: A challenger to the throne of vector graphics by CamperBob2 on Monday December 20, 2021 @06:02PM (#29631641)

90+% of real-world SVG files display just fine with NanoSVG, just to name one of several small SVG renderers that are already available. And it's not one of those Microsoft Office scenarios where the 90% subset is slightly different for every user.

So I don't really see the point in introducing any new vector graphic formats. Just define a subset of SVG that supports the features commonly in use, give it a name, and adopt one of the existing lightweight renderers, forking it if necessary.

As others have pointed out, representation size doesn't matter because it'll be compressed anyway in any applications where size is important. Plain old text is fine.

[ Parent | on HN ]

Re:TinyVG: A challenger to the throne of vector graphics by ikskuh on Monday December 20, 2021 @06:14PM (#29631745)

So i did the dance with a single file (my starter file):

It's the "shield-account" from material design.

    353 shield.svg
    246 shield.svg.gz
    119 shield.tvg
    139 shield.tvg.gz

Looks like tvg is so well compressed that using gzip compression doesn't help and beats compressed and optimized svg still by a magnitude of two. We'll get better numbers when i find time to improve the benchmark.

TinyVG was also designed to be used on constrained embedded systems with low RAM, and i have a proof of concept that it can render medium complexity files with less than 32k RAM without memory optimizations in the reference implementation. NanoVG doesn't seem to support streaming render events either, so it isn't suitable for low memory profiles as it creates a DOM that will be rendered

[ Parent | on HN ]