TinyVG – an alternative binary encoded vector graphics format

The author would make an even stronger case if they showed the results <i>after</i> compression. On the few examples in the home page, which I compressed with gzip -9 (zstd performs similarly):<p><pre><code> tiger.svg.gz 29834 tiger.tvg.gz 20533 app-icon.svg.gz 613 app-icon.tvg.gz 665 comic.svg.gz 25063 comic.tvg.gz 13262 chart.svg.gz 8311 chart.tvg.gz 5369 </code></pre> In most cases, even after gzip compression TVG still has a substantial lead over SVG.<p>This is evidence that the size improvement does not come entirely from the binary format (it would be possible to devise a binary format for SVG without changing the language and semantics), but from the simplified graphic primitives as well. If it was just XML overhead, compression should mitigate most of it.

By far the biggest advantage of SVG on the web is DOM integration, thanks to its choice of XML. This enables, among other things,<p>- Trivial adaptive styling: the simplest case would be matching color of surrounding text;<p>- Easy and relatively cheap dynamic updates to individual components, trivially integrated with any DOM-manipulation tech, including declarative frameworks big and small.<p>I don&#x27;t see a binary format easily replicating those.<p>Edit: Of course it&#x27;s okay to have more opaque binary formats.

Three cheers!!!<p>So fine with new and actually improved technologies instead of the many GUI rehashes that some companies make money off delivering all the time.<p>I don&#x27;t often use SVG, and am by no means an expert on it, but I dislike the experience every time. Like having to edit an .SVG file to fix a wrong displacement that places it a bit too far down. Trial and error, trial and error, until you randomly hit the spot that makes the thing begin to behave.<p>I think TVG popularity boils down to browser support and nothing else. I hope somebody with the skills picks up the task of integrating it into Chromium, then the rest of the world will bend and bow quickly.<p>Also, one might hope that a freeware GUI editor will see the light in not too long.<p>Perhaps the authors should do a new single-protocol Mail&#x2F;Calendar&#x2F;Contacts&#x2F;Notes&#x2F;etc. standard as well? I recall IMAP being a horribly clumsy and complex protocol, and didn&#x27;t Einstein say:<p><pre><code> Make it as simple as you can, but not simpler!</code></pre>

I&#x27;m going to sound like Richard Stallman, but being human-readable and Notepad-accessible is a <i>huge</i> advantage for SVG compared to this and its binary nature.

Senseless, if you not explain what will work with TinyVG and what will not work.<p>Tried some real life svg files from a current project, all failed: `Node has unsupported transform:` matrix, translate, Failed to translate color spec rgb, ... The transformed files are all larger.<p>All files are simple SVG without any special content. Exportet from Affinity Designer.

SVG integrates with CSS, animations and is a 1st class citizen on the web.<p>I hardly see any way tinyVG (binary) could replace that. But for displaying vector graphics like images, size perf is great :)

What part of SVG does TinyVG NOT support?<p>If I would want to replace my current usage if SVG with TinyVG I would like to know what isn&#x27;t supported, before I start replacing.

A lot of people are defending SVG by pointing out how it integrates with CSS and JS the DOM and I&#x27;m like &quot;yes that&#x27;s why a simpler format is better&quot;. SVG is too powerful to use as a simple image format.<p>Everybody trusts user-uploaded JPGs. Trusting user-uploaded svgs is dangerous without detailed domain knowledge.<p>Json vs XML already demonstrated how less is more.<p>There are good reasons to enjoy the idea of a vector graphics equivalent to HTML just like there are good reasons to enjoy a vector graphics equivalent to PNG.

I want to like this more, but it doesn&#x27;t seem very compelling.<p>As others have noted, the size difference is essentially nil if you compare to a gzipped <i>minified</i> SVG (for which there are off-the-shelf tools).<p>No CSS means you can&#x27;t easily integrate with CSS animations.<p>The spec also seems unnecessarily quirky -- I would have expected it to be really, really simplistic and minimal, along the lines of <a href="https:&#x2F;&#x2F;qoiformat.org" rel="nofollow">https:&#x2F;&#x2F;qoiformat.org</a>. For example, there&#x27;s a header flag that sets the &quot;unit&quot; size to 1, 2 or 4 bytes; but <i>also</i> a variable-length encoding for values, so it seems like small uint32 units would mostly fit into 1 byte anyway. Only sRGB colors are supported -- why not linear?<p>I&#x27;d definitely prefer to write a renderer for TinyVG rather than SVG if I were working from scratch. But SVG exists and is pretty well-supported already so you don&#x27;t have to. (And if I enjoyed working with XML I might actually prefer SVG.)<p>Possibly TinyVG would be good for embedded systems? If there were a really small and fast implementation, <i>and</i> if anyone has a need for portable vector graphics on a system that can&#x27;t handle SVG.

If we ZIP both SVG and TVG, the difference is not that large anymore.<p>For most of people, wide support is more important than 20% smaller file size. That is why it is hard for WEBP to replace JPG.

This looks pretty impressive. They&#x27;ve got an official specification up at: <a href="https:&#x2F;&#x2F;github.com&#x2F;TinyVG&#x2F;specification">https:&#x2F;&#x2F;github.com&#x2F;TinyVG&#x2F;specification</a><p>Also, interestingly, it&#x27;s written in Zig: <a href="https:&#x2F;&#x2F;github.com&#x2F;TinyVG&#x2F;sdk">https:&#x2F;&#x2F;github.com&#x2F;TinyVG&#x2F;sdk</a>

&quot;SVG is a horribly complex format and an overkill for most projects&quot;<p>Can this be given more substance..?<p>Does it also apply to SVG v1.1 (Tiny&#x2F;Basic)? It seems to cover a similarity limited scope. From the landing page its unclear if its fundamentally doing something different. In my naiive perspective itd seem more sensible to just make a new way to encode SVG?

I always found SVG a non-readable file for most images I’ve used. Yes, if you place a simple rectangle it works, but when you export an image it’s almost impossible to edit it manually.<p>I like this edge on TVG, as a binary format is more optimal for size and you’re not losing much visibility on this case.<p>I believe TVG popularity will depend on the final use cases. Having to use a poly fill on the browser delays the reproduction of the image until JS is loaded. It would be interesting to compare both cases: download an optimized SVG vs download and print a TVG file using the polyfill.

It compares only to SVG. How about other formats? e.g. Lottie-based .TGS format, Microsoft&#x27;s .EMF.

The spec v1.0 was written two years ago. Is anyone using this new file format?

Related:<p><i>TinyVG: A challenger to the throne of vector graphics</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=29629792" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=29629792</a> - Dec 2021 (187 comments)

There&#x27;s already a very good binary encoded vector graphics format, which also supports animation among other things --- SWF. The descriptions in this specification actually look somewhat like it.<p><i>The original SVG is 96,719 bytes large, while the optimized one is 85,806 bytes large. When converted to TinyVG, the file shrinks to 27,522 bytes. This means we only have 32% size of the optimized source data.</i><p>I have a tiger.swf which is 21381 bytes, and since there&#x27;s another comment here about gzip&#x27;ing them, tiger.swf.gz turns out to be only 17296 bytes. In conclusion, I think a subset of SWF, of which much existing rendering code is available, will provide much better efficiency and compatibility than this.

IMO binary encoded versions of files that are already small are more hassle than they&#x27;re worth. Now you need a specialized tool to view and edit the file. I have, on many occasions, edited SVGs manually in a text editor. Losing that is a big devex issue.<p>Having worked a bit with protobuf and CBOR in the last year - the binary encodings are a big pain in the ass. I understand that for massive companies the payoff could be worth it (although I think the people that decide to use proto&#x2F;CBOR don&#x27;t calculate the hours wasted on an obtuse encoding scheme), but <i>certainly</i> for small shops you&#x27;re wasting your time.

Is TinyVG faster to render than SVG? That would be a good justification to use it.

Disclaimer: dumb questions ahead.<p>Who is this project intended for? I was under the impression that browsers and Adobe products implement their own VG renderers (not client-side JS code provided by websites).<p>If that&#x27;s correct, is this project trying to build a format that&#x27;s better than SVG and parseable out-of-the-box by those renderers?<p>Or is it trying to get browsers&#x2F;Adobe to extend their renderers to support TinyVG? If this is true and TinyVG isn&#x27;t supported yet, how was the website able to render that Tiger picture?

I wish the website briefly list the features that exist in the SVG format but doesn&#x27;t exist in theirs, so I could see exactly what I&#x27;m missing. It could remove a lot of doubt to dip my toe if it turns out that I really don&#x27;t need the missing features.

you get an edge over size with binary formats, but it&#x27;s a pain to edit on the fly - svg has relatively low barrier to entry in this respect.<p>perhaps a TVG niche could be around embedded, low-power, slow-connection devices where content is mainly read-only.

Been thinking about using webassembly to compile something like this, then you build the callouts to do the actual rendering... could potentially be even smaller. Compile TinyVG &gt; Wasm &gt; Wasm to bytecode.

Does anyone know what the edge cases SVG concentrates on are?

Sounds a little like an early version of Flash. Size comparisons to SVG after compression would be interesting too as most Web assets will be delivered compressed.

Are there any Python&#x2F;MicroPython libraries being worked on for this? This could be helpful for micro controller graphics.

How does TinyVG compare against WebCGM<p>Comparing binary format vector graphics against SVG as if there is nothing else seems weird.

Seems like a good way to protect your vector graphics from being nabbed if it&#x27;s encoded in bin.

The “plain text” spec is in a weird encoding, casing mojibake when I view it in my browser.

What features does it miss from SVG?

Nice.<p>I like how styles are defined up top and referenced thereafter.<p>Maybe modify the header from &#x27;lisp&#x27; to a shebang, like:<p>#!tinyvg

Good luck getting browser support so it’s actually usable

It seems lots of people are discovering that SVG is overkill for most applications. Here (<a href="https:&#x2F;&#x2F;docs.google.com&#x2F;document&#x2F;d&#x2F;1YWffrlc6ZqRwfIiR1qwp1AOkS9JyA_lEURI8p5PsZlg&#x2F;edit" rel="nofollow">https:&#x2F;&#x2F;docs.google.com&#x2F;document&#x2F;d&#x2F;1YWffrlc6ZqRwfIiR1qwp1AOk...</a>) is a document by the flutter devs where they outline a new format. I hope we won&#x27;t end up in a situation where there are 14 competing successor candidates for SVG.