It's common to think of vector art of 'ground truth' and bitmaps as sampled image, but SVG and TinyVG don't add so much over bitmaps. When you zoom into 100-point polygon, you still reach the limit where there is no additional details. Those 100 points are in fact samples, an approximation of artist's intention. When boolean operations are preformed on polygons, information gets lost and the shapes degenerate. The SDFs in 3D modeling seem more pure way of defining and manipulating shapes than polygons and bezier curves.
TinyVG doesn't implement node referencing. In SVG it is done by the `clone` operation, which creates SVG node that references original shape. Using this you can build smart scenes with shadows, reflections, arrayed clones and other interesting effects. It's like DRY principle for art; you can later modify the original shape and see changes reflected in other parts of the scene.
TinyVG doesn't even seem to have object groups. If I wanted to draw a gauge and control needle rotation in runtime I would have to manually re-compute path coordinates each frame. In SVG I would group all parts the gauge needle, and in each frame I would update just the rotation angle in group transform.
For a vector format to de-throne the SVG I would expect it to be smarter than SVG while discarding legacy features. I'd like to see things like infinitely large dimensions for shapes (shapes for ground and sky, or a ray of sun), specifying design constraints, interactivity and procedural animations. IMO the TinyVG takes vector graphics into wrong direction, as a boring subset of SVG.
Edit: I like that TinyVG takes form of very readable lisp-like data description language. Maybe it could be used as a starting point for a smarter vector format for authoring graphics and not just for distributing the end results.
Most uses today of SVG, that I have seen in the wild are icons, graphs and diagrams. Which this TinyVG covers beautifully. Especially for embeded (TinyVG's authors motivation for this) you often need some icons.
Sure if you need something more complex keep using SVG, or create something new.
But for 80% - 90% off web and embedded its enough.
> TinyVG doesn't implement node referencing. In SVG it is done by the `clone` operation, which creates SVG node that references original shape. Using this you can build smart scenes with shadows, reflections, arrayed clones and other interesting effects. It's like DRY principle for art; you can later modify the original shape and see changes reflected in other parts of the scene.
TinyVG is final format optimized for rendering. You can design your graphic with all those futures, and then render them to TinyVG.
DRY doesn't apply since you will not be writing it by hand anyway, but use a tool.
Author clearly states that this is not an Authoring format, but display format.
What you are looking for is better authoring format.
> Edit: I like that TinyVG takes form of very readable lisp-like data description language. Maybe it could be used as a starting point for a smarter vector format for authoring graphics and not just for distributing the end results.
That's not TinyVG format. That is just sample generator that comes with TinyVG suite. TinyVG is binary format, and you can't edit it with text editor
For web and embedded I would still need to dynamically control transforms of object groups. Otherwise the graphics is baked and I can just as well use PNG.
Just like bitmaps, vector graphics looks best when it is displayed at size it was designed for. Too small and details will just blur together; too large and the design looks overly simple with unnaturally sharp edges.
> For web and embedded I would still need to dynamically control transforms of object groups.
Looking at what people mostly use SVG's for on the web, most people don't agree with you. Like I said most SVG's I see are either static icons, diagrams or graphs.
Weather it would be better for them to be bitmaps is another discussion. Lately in embedded I often come in situation where I have CPU cycles to spare, but bump into available storage limit on micro. So this might make sense in such situation
Whole point of this format is to be 80%. that's why it has tiny in name :) If you want to do dynamic content this is not format for you.
> Otherwise the graphics is baked and I can just as well use PNG.
that's what I use now.
But I will try this TinyVG for my next projects dashboard icons, to see cpu/storage space is favorable
TinyVG doesn't implement node referencing. In SVG it is done by the `clone` operation, which creates SVG node that references original shape. Using this you can build smart scenes with shadows, reflections, arrayed clones and other interesting effects. It's like DRY principle for art; you can later modify the original shape and see changes reflected in other parts of the scene.
TinyVG doesn't even seem to have object groups. If I wanted to draw a gauge and control needle rotation in runtime I would have to manually re-compute path coordinates each frame. In SVG I would group all parts the gauge needle, and in each frame I would update just the rotation angle in group transform.
For a vector format to de-throne the SVG I would expect it to be smarter than SVG while discarding legacy features. I'd like to see things like infinitely large dimensions for shapes (shapes for ground and sky, or a ray of sun), specifying design constraints, interactivity and procedural animations. IMO the TinyVG takes vector graphics into wrong direction, as a boring subset of SVG.
Edit: I like that TinyVG takes form of very readable lisp-like data description language. Maybe it could be used as a starting point for a smarter vector format for authoring graphics and not just for distributing the end results.