TinyVG – an alternative binary encoded vector graphics format
tinyvg.tech
tinyvg.tech
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
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.
Strong enough compression should mitigate most of it, but DEFLATE (and consequently zip and gzip) is not a strong enough algorithm.
For example, let's imagine that a particular format is available both in JSON and in a binary format and is entirely composed of objects, arrays and ASCII strings, so binary doesn't benefit much from a compact encoding. Now consider a JSON `[{"field1":...,"field2":...,...},...]` with lots of `fieldN` strings duplicated. DEFLATE will be able to figure out that `","fieldN":"` fragments frequently occur and can be shortened into a backreference, but that backreference still takes at least two bits and normally a lot more bits (because you have to distinguish different `","fieldN":"` fragments), so they will translate to pure overhead compared to compressed binary.
Modern compression algorithms mainly deal this pattern with two ways, possibly both. The backreference can be encoded to fractional number of bits, implying the use of arithmetic/range/ANS coding (cf. Zstandard). Or you can recognize different token distributions for different contexts (cf. Brotli). They do come with non-negligible computational overhead though and became only practical recently with newer techniques.
`svgo` gives 61698 / 21642 gz / 20228 zstd, again no visual difference.
Not really a need for TVG if you can clean your SVG as part of your deployment pipeline.
(You can go even further and trim the coordinates to 2 places of precision which ends up with 52763 / 18299 / 17114 zstd at the expense of still largely invisible differences but I've had SVGs where this level of cleaning did materially affect the output.)
Somebody recently pointed me at a nice online GUI for svgo, so you can try it for yourself without installing anything: https://jakearchibald.github.io/svgomg/
Did you try converting svgcleaner processed SVG to a TVG?
I would but I can't build the SDK (gets some zig error about failing to add a package) and the darwin-arm downloads don't include `svg2tvg`.
If I use the darwin-x86 download, `svg2tvgt` can't convert the file - `UnitRangeException: NaN is out of range when encoded with scale 1`.
I guess it doesn't really parse all SVGs.
Maybe we need a TVGCleaner too.
I think you'd generally only use the cleaning / optimising step when deploying / packaging the asset - you'd leave the original as, well, the original for further editing (and to take advantage of better optimisations if they come about.)
I've worked with enough people who only had the optimized assets because "Well optimized is better, right?" [0] that I thought it was worth pointing out.
[0] I was working on some web stuff for them and they were curious if I could also do some graphics work, small local company
All of this of course at the risk of https://imgs.xkcd.com/comics/standards.png
Easier for the browser to process? Well that’s going to have a tonne of useful ramifications.
Honestly that’s what annoys me about web services in general. (Rant mode enabled). The human readability aspect is moot because conversion is cheap, yet everything these days is built on XML, JSON and YAML.
The increasing use of middleman services whose entire job is to parse these formats into native types, then process the data, then serialise back into the same inefficient format, makes the issue a whole lot worse.
I mean, sure, this stuff is used so heavily that some amazing work has gone into parsing with SIMD at ridiculously high rates, but this is still orders of magnitude more time and effort for a CPU to perform the same thing with a native format. Even for things like strings, an actually-sensible representation like [length][body] would save all kinds of hassle by avoiding processing delimiters, searching for quotes, etc, and would make loading a value as simple as allocating the ALREADY KNOWN size and reading it.
Anyway, that’s my rant. The more parse-friendly formats out there the better.
- Trivial adaptive styling: the simplest case would be matching color of surrounding text;
- Easy and relatively cheap dynamic updates to individual components, trivially integrated with any DOM-manipulation tech, including declarative frameworks big and small.
I don't see a binary format easily replicating those.
Edit: Of course it's okay to have more opaque binary formats.
SVG is so bad people have been using fonts instead (which are binary).
And 99.9% of people who use SVG are doing it with illustrator or inkscape anyway, the binary vs text argument here seems totally irrelevant.
Guess what “DOM integration” means.
> SVG is so bad people have been using fonts instead
Icon fonts have been out of fashion for so long I almost suspect you time traveled from the past.
Does it mean unusably inconvenient? Because that's what I call having to embed SVGs just so CSS works with them.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ob...
Would you expect a parent's CSS to affect HTML in an iframe, a separate document context? That would be confusing behavior to be sure. Side effects galore.
The use case for styling external SVGs with CSS is waaay more obvious. We should at least have the option to do it, even if it isn't enabled by default.
* font rendering issues
* rendering improvements
* accessibility
* ease of authoring
* can be animated
https://github.blog/2016-02-22-delivering-octicons-with-svg/....
For all intents and purposes with regard to web development, fonts have been monochromatic (except for emojis). Any with sufficient knowledge gathered over decades can write/edit an SVG in the editor of their choice, graphical or textual.
How does one edit their own color font? Can you do it in a text editor? Do most font editing programs support it? Or were you speaking of fonts purely as a consumer rather than a producer?
Right, and this is actually pretty common -- you can use <svg> tags directly in JSX, and you can set up a build pipeline that lets you import .svg files directly into your .jsx/.tsx.
It's useful because you can do things like animate your SVG using CSS, driven from the JS/JSX code.
And for complex animations you resort to Lottie. So interacting with SVG via its DOM API is incredibly rare.
You're contradicting yourself here.
> ... which requires stripping the `<?xml` and `<!DOCTYPE`, which requires an xml parser/serializer
That doesn't make sense either. Removing the XML declaration and the doctype declaration can be done using the same editor you're using for your HTML at hand - unless you're referencing the SVG as external resource via href, and then you don't need to remove it all. XML and doctype declaration aren't needed for XML conformance anyway, and your tool should offer an option to export without these.
Note according to the WHATWG HTML spec (redacted snapshots of which used to be known as W3C HTML 5.x until recently) when used embedded in HTML, SVG content is actually parsed using HTML/generic SGML rather than XML rules. For example, unlike in XML, element/tag and attribute names can be written in any mix of lowercase/uppercase chars, etc.
All of my data viz code is React-controlled SVGs, for instance. I was able to implement generic zoom and pan on top of this. Also things like nested graphs look good in SVG
That's a weird claim, since most of my SVG customizations are done using CSS.
> SVG is so bad people have been using fonts instead (which are binary).
No they're not, SVG is far more popular than icon fonts, which has been in steady decline for years.
> And 99.9% of people who use SVG are doing it with illustrator or inkscape anyway
False again. SVG is a popular export format for myraid of desktop, mobile & online design & publishing tools and presentation software which I've used over the years, none of which were Illustrator or Inkscape. I've also hand edited lots of SVGs to customize it to look how I want, which isn't feasible for Icon fonts.
So fine with new and actually improved technologies instead of the many GUI rehashes that some companies make money off delivering all the time.
I don'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.
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.
Also, one might hope that a freeware GUI editor will see the light in not too long.
Perhaps the authors should do a new single-protocol Mail/Calendar/Contacts/Notes/etc. standard as well? I recall IMAP being a horribly clumsy and complex protocol, and didn't Einstein say:
Make it as simple as you can, but not simpler!The spec for PDF 1.7 (dated 2008) is 745 pages long. The more modern PDF 2.0 is not freely available. I'm not willing to spend hundreds of euros to get access to the document, but together with the long list of errata and additional documents linked from the standard body's website, I'm willing to bet it's at least equivalent in length to PostScript.
PDF has a lot of features that I would never think of myself (pronunciation guides, for example) which would require designing a custom solution for in many other formats such as SVG.
If I wanted to render something to be printed and I wanted it to be printed exactly as specified, I would consider PDF (and PostScript) files to be much more reliable than SVG files. SVGs are great for images and icons, but they're simply not designed to do the things PDF was designed to do.
Conversely, PDFs are difficult to embed and require proprietary tools to use most of their less common features, so in many areas they're much worse than SVGs.
Not really, because the JavaScript is quite limited in what it can do (e.g. forms and interactive features). It can't produce text or graphical elements. A PDF reader can show view of a PDF that looks correct even if it doesn't implement any of the JavaScript features.
It's enough to play Breakout inside a PDF: https://youtu.be/6rbJu10Telc?t=483
SVG is a very impressive, extremely clear format with many bells and whistles such as text-to-path and animation built-in.
The only improvement I can see it might need is a better compression functionality that can selectively prioritize symbols to load first if the SVG is sufficiently large.
Have you tried Inkscape for editing SVGs? It’s more of an Adobe Illustrator wannabe but it’s not half bad.
SVG is weird among image format in that it is XML. It requires a lot of effort to parse and render.
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.
All files are simple SVG without any special content. Exportet from Affinity Designer.
I hardly see any way tinyVG (binary) could replace that. But for displaying vector graphics like images, size perf is great :)
If I would want to replace my current usage if SVG with TinyVG I would like to know what isn't supported, before I start replacing.
Everybody trusts user-uploaded JPGs. Trusting user-uploaded svgs is dangerous without detailed domain knowledge.
Json vs XML already demonstrated how less is more.
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.
As others have noted, the size difference is essentially nil if you compare to a gzipped minified SVG (for which there are off-the-shelf tools).
No CSS means you can't easily integrate with CSS animations.
The spec also seems unnecessarily quirky -- I would have expected it to be really, really simplistic and minimal, along the lines of https://qoiformat.org. For example, there's a header flag that sets the "unit" size to 1, 2 or 4 bytes; but also 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?
I'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't have to. (And if I enjoyed working with XML I might actually prefer SVG.)
Possibly TinyVG would be good for embedded systems? If there were a really small and fast implementation, and if anyone has a need for portable vector graphics on a system that can't handle SVG.
sRGB is smaller for storage. All actual calculations (alpha blending, gradients) are already done in linear space.
I'm not sure doing calculations in linear space is actually a good idea though. Most art programs and the web use sRGB, so accurate conversion isn't possible.
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.
Like you said, support is what matters. SVG is notoriously difficult to implement and it took forever to be supported everywhere, which also contributed to the persistence of Flash. TVG is supposed to be easy to implement, which seems to be to be the advantage.
JPEG, by contrast, is a pretty simple format with only a few minor quirks.
But then you haven't implemented SVG. You can't say "we support SVG", and you lack a good way to communicate what users can expect from your implementation. It's much easier to communicate clearly when you can implement a whole standard rather than a haphazard subset of one.
Also, parsing overhead is such a tiny fraction of the overall effort (in either case) it doesn't really mean anything.
Also, interestingly, it's written in Zig: https://github.com/TinyVG/sdk
Can this be given more substance..?
Does it also apply to SVG v1.1 (Tiny/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?
Maybe there isn't any need for a simpler vector graphics format because no one is using TinyVG, either.
So anyone who supports svg 1.1 supports this automatically. I guess it helpa define/narrow a small svg subset to target if you write a new renderer. For instance rendering with JavaFX primitives, this would maybe be achievable
And this new thing also sounds kinda like a subset of svg..
It's pretty bad marketing to call a different product by the same name. Particularly when it chooses a totally different side of the trade-off versus its homonym. Not only have I never heard of SVG Native, I'm confident that I'm going to forget what it is in a few days because I don't have a proper name to remember it by. Also, the adjective "native" here gives me no useful information as to what problem it tries to solve — how do I infer "simplified" from "native"?
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.
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.
TinyVG: A challenger to the throne of vector graphics - https://news.ycombinator.com/item?id=29629792 - Dec 2021 (187 comments)
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 have a tiger.swf which is 21381 bytes, and since there's another comment here about gzip'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.
Even though Adobe owns SWF, they don't support it in Illustrator outside of exporting.
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/CBOR don't calculate the hours wasted on an obtuse encoding scheme), but certainly for small shops you're wasting your time.
But while we are at that, I wish SVG rendering of large paths on Chrome would be as fast as it was before hardware "acceleration" was introduced.
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).
If that's correct, is this project trying to build a format that's better than SVG and parseable out-of-the-box by those renderers?
Or is it trying to get browsers/Adobe to extend their renderers to support TinyVG? If this is true and TinyVG isn't supported yet, how was the website able to render that Tiger picture?
perhaps a TVG niche could be around embedded, low-power, slow-connection devices where content is mainly read-only.
void draw_tiger(ctx) {
ctx.setFillColor(255, 255, 255);
ctx.beginPath();
ctx.moveTo(124, 56);
// etc
}Comparing binary format vector graphics against SVG as if there is nothing else seems weird.
I like how styles are defined up top and referenced thereafter.
Maybe modify the header from 'lisp' to a shebang, like:
#!tinyvg
[1] https://developer.android.com/develop/ui/views/graphics/vect...