14 ms·

TinyVG – an alternative binary encoded vector graphics format

345 points by tsujp 4y ago

IvanK_net 4y ago
If we ZIP both SVG and TVG, the difference is not that large anymore. 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.
- scythe 4y ago
  I don't think the size is a key advantage here, even if it were true. 96 kilobytes simply isn't very big to start with, considering most of the content that gets sent around. 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.
  - IvanK_net 4y ago
    If someone already implemented an XML parser for you, SVG is easier to implement than TVG (if you are trying to extract the same type of content out of SVG as out of TVG).
    - scythe 4y ago
      >if you are trying to extract the same type of content out of SVG as out of TVG 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.
DeathArrow 4y ago
Is TinyVG faster to render than SVG? That would be a good justification to use it.
- jansan 4y ago
  Probably not, because it is just a file format, which does not specify how things are rendered. 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.
- TUSF 4y ago
  Its simpler format should make it faster to parse & decode, at least. Whether that might affect render times is likely to depend on the renderer itself.
lalaithion 4y ago
The “plain text” spec is in a weird encoding, casing mojibake when I view it in my browser.
veqq 4y ago
Does anyone know what the edge cases SVG concentrates on are?
est 4y ago
It compares only to SVG. How about other formats? e.g. Lottie-based .TGS format, Microsoft's .EMF.
- Narishma 4y ago
  Are those open formats?
winter_blue 4y ago
This looks pretty impressive. They've got an official specification up at: https://github.com/TinyVG/specification https://github.com/TinyVG/specification Also, interestingly, it's written in Zig: https://github.com/TinyVG/sdk https://github.com/TinyVG/sdk
FreeTrade 4y ago
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.
Dalewyn 4y ago
I'm going to sound like Richard Stallman, but being human-readable and Notepad-accessible is a huge advantage for SVG compared to this and its binary nature.
- ianburrell 4y ago
  I think there is a place for rich text and compact binary formats. Then can pre-render from complicated source to produce smaller and faster binary format. You would edit the SVG and then make TinyVG (and minified SVG). SVG is weird among image format in that it is XML. It requires a lot of effort to parse and render.
- detrites 4y ago
  You may have missed that it has both a binary and a text version.
  - montag 4y ago
    Yes, but the text version is "not required to be implemented by conforming implementations". The wrong tradeoff, in my opinion.
    - detrites 4y ago
      It's optional, so if the need you identified exists it will be implemented. Its essential selling-point is compactness, so being the target, the path of least resistance should be optionally allowing the text-form, not building around it.
- rcoveson 4y ago
  What does "Notepad-accessible" mean? Surely you're not referring to notepad.exe in a sentence beginning with "I'm going to sound like Richard Stallman"?
angelmm 4y ago
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. 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.
- easrng 4y ago
  idk i export SVGs from inkscape and edit them by hand pretty frequently, it's not that hard.
  - angelmm 4y ago
    For me most changes are related to colors and text. Paths are quite difficult to edit.
    - easrng 4y ago
      oh yeah i don't edit paths by hand, just stuff like cleaning up groups, removing unused css, changing colors, etc. when i do need to edit paths i use https://yqnn.github.io/svg-path-editor/ https://yqnn.github.io/svg-path-editor/
abdellah123 4y ago
SVG integrates with CSS, animations and is a 1st class citizen on the web. I hardly see any way tinyVG (binary) could replace that. But for displaying vector graphics like images, size perf is great :)
geokon 4y ago
"SVG is a horribly complex format and an overkill for most projects" 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?
- fbdab103 4y ago
  Just casually browsing the SVG spec[0] looks like it covers a lot of ground. Different coordinate systems, CSS styling, paths, clipping, filters, animations, scripting, fonts etc. There needs to be an open vector format that supports all of those things, but maybe it is inappropriate that this is what get shipped by default. [0]: https://www.w3.org/Graphics/SVG/1.1/ https://www.w3.org/Graphics/SVG/1.1/
  - easrng 4y ago
    tf are you on, paths and clipping are essential.
  - gardaani 4y ago
    SVG Native was supposed to fix that [1]. SVG Native uses only one coordinate system, no CSS styling, no filters, no animation, no scripting and no text or fonts. However, it didn't get much interest and it's starting to look like a dead version of SVG. Maybe there isn't any need for a simpler vector graphics format because no one is using TinyVG, either. [1] https://w3c.github.io/svgwg/specs/svg-native/index.html https://w3c.github.io/svgwg/specs/svg-native/index.html
    - geokon 4y ago
      “SVG Native is a subset of SVG 1.1, which removes animation, interactivity, linking, remote resource loading, scripting, and CSS ” 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..
archfrog 4y ago
Three cheers!!! 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!
- fbdab103 4y ago
  If we are really talking wish lists, I dream of a simplified PDF spec.
  - signaru 4y ago
    Also a simplified font spec while we're at it? While there are libraries for it, it is apparently discouraging if you wanted to code your own parser for the existing font formats.
  - john61 4y ago
    Postscript?
    - mkl 4y ago
      Unlike PDF, PostScript is a full Turing-complete programming language, capable of far more document complexity than PDF (though less interactivity). The PostScript Language Reference Manual is 900 pages, and the PostScript Language Reference Supplement is another 160.
      - 4y ago
gardaani 4y ago
The spec v1.0 was written two years ago. Is anyone using this new file format?
ot 4y ago
The author would make an even stronger case if they showed the results after compression. On the few examples in the home page, which I compressed with gzip -9 (zstd performs similarly): 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 In most cases, even after gzip compression TVG still has a substantial lead over SVG. 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.
- dolmen 4y ago
  I see much more gain in TinyVG in CPU usage to decode and render an image. XML is definitely not the most efficient way to expose data that is not meant for human consumption.
  - Mikhail_Edoshin 4y ago
    XML, of course, is an opposite: It is a rather good way for humans to create data meant for computer consumption. Once the data are laid out, they can be transformed into a more efficient machine form in the same way a program is compiled, but for the web this is rarely done for any format, including pure machine-to-machine interaction. E.g. JSON is mostly used for machine-to-machine exchange and it is far from begin efficient for this.
  - i-use-nixos-btw 4y ago
    That would be what I’d care about the most. Smaller file size, but not an order of magnitude difference? Meh. 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.
deleted 4y ago
[deleted]
giomasce 4y ago
What features does it miss from SVG?
nomercy400 4y ago
What part of SVG does TinyVG NOT support? 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.
progx 4y ago
Senseless, if you not explain what will work with TinyVG and what will not work. 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.
- iainmerrick 4y ago
  Those sound like missing features in the importer rather than an actual gap in the spec. Transforms and different color spaces could be baked into the data at import time.
  - deleted 4y ago
    [deleted]
oefrha 4y ago
By far the biggest advantage of SVG on the web is DOM integration, thanks to its choice of XML. This enables, among other things, - 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.
- rendaw 4y ago
  SVG is firewalled off from js and css regardless of how you use it. The only way to practically interact with SVG content (i.e. make it actually more useful than a jpg) you need to embed it directly, which requires stripping the `<?xml` and `<!DOCTYPE`, which requires an xml parser/serializer. 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.
  - oefrha 4y ago
    > you need to embed it directly. 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.
    - IshKebab 4y ago
      > Guess what "DOM integration" means. Does it mean unusably inconvenient? Because that's what I call having to embed SVGs just so CSS works with them.
      - ttfkam 4y ago
        Hold up. Are you blaming SVG because you don't know the <object> tag exists? I mean, yeah, you're right that CSS won't come through with an <img> tag. It will with <object> though. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/object https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ob...
ar9av 4y ago
It seems lots of people are discovering that SVG is overkill for most applications. Here (https://docs.google.com/document/d/1YWffrlc6ZqRwfIiR1qwp1AOkS9JyA_lEURI8p5PsZlg/edit https://docs.google.com/document/d/1YWffrlc6ZqRwfIiR1qwp1AOk...) is a document by the flutter devs where they outline a new format. I hope we won't end up in a situation where there are 14 competing successor candidates for SVG.
- gardaani 4y ago
  Google also has Vector Drawables for Android [1]. I'm sure they'll also create the other 12 competing successors, because each of their platforms need a new separate format. [1] https://developer.android.com/develop/ui/views/graphics/vector-drawable-resources https://developer.android.com/develop/ui/views/graphics/vect...
  - droidist2 4y ago
    Facebook/Meta will create a 15th standard; people will decry it for not following one of the previous 14 standards, but everyone will adopt it. Then Google will re-release one of their 14 but change everything to look more like Meta's.
- AnIdiotOnTheNet 4y ago
  Too late. Here's another one: https://en.wikipedia.org/wiki/Haiku_Vector_Icon_Format https://en.wikipedia.org/wiki/Haiku_Vector_Icon_Format
  - kevin_thibedeau 4y ago
    HVIF isn't general purpose. It's solely focused on icons and sacrifices precision for the sake of more compact encoding.
deleted 4y ago
[deleted]
al_be_back 4y ago
you get an edge over size with binary formats, but it's a pain to edit on the fly - svg has relatively low barrier to entry in this respect. perhaps a TVG niche could be around embedded, low-power, slow-connection devices where content is mainly read-only.
- edflsafoiewq 4y ago
  At that end it competes against compiling your graphic directly to source code, eg void draw_tiger(ctx) { ctx.setFillColor(255, 255, 255); ctx.beginPath(); ctx.moveTo(124, 56); // etc }
iainmerrick 4y ago
I want to like this more, but it doesn't seem very compelling. 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 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.
- edflsafoiewq 4y ago
  > Only sRGB colors are supported -- why not linear? 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.
dang 4y ago
Related: TinyVG: A challenger to the throne of vector graphics - https://news.ycombinator.com/item?id=29629792 https://news.ycombinator.com/item?id=29629792 - Dec 2021 (187 comments)
nabla9 4y ago
How does TinyVG compare against WebCGM Comparing binary format vector graphics against SVG as if there is nothing else seems weird.
ha1zum 4y ago
I wish the website briefly list the features that exist in the SVG format but doesn't exist in theirs, so I could see exactly what I'm missing. It could remove a lot of doubt to dip my toe if it turns out that I really don't need the missing features.
Pxtl 4y ago
A lot of people are defending SVG by pointing out how it integrates with CSS and JS the DOM and I'm like "yes that's why a simpler format is better". SVG is too powerful to use as a simple image format. 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.
Dork1234 4y ago
Are there any Python/MicroPython libraries being worked on for this? This could be helpful for micro controller graphics.
1-6 4y ago
Seems like a good way to protect your vector graphics from being nabbed if it's encoded in bin.
userbinator 4y ago
There'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. 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.
- mcdonje 4y ago
  SWF is flash. Vector graphics are just a subset of the format. Any tool claiming to support that format would have to support the rest of the spec, which is overkill for many vector applications. Even though Adobe owns SWF, they don't support it in Illustrator outside of exporting.
  - userbinator 4y ago
    Plenty of existing tools only support a subset of SWF, mainly the vector graphics and animation parts. It's used for UIs in games and various other applications. https://en.wikipedia.org/wiki/Gameswf https://en.wikipedia.org/wiki/Gameswf
  - account42 4y ago
    You can always pull a marketing stunt like .webm vs. Matroska if you want to advertise support for a variant of Flash constrained to just the vector parts.
- Narishma 4y ago
  Is there a spec for SWF?
  - robterrell 4y ago
    https://open-flash.github.io/mirrors/swf-spec-19.pdf https://open-flash.github.io/mirrors/swf-spec-19.pdf
bigattichouse 4y ago
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 > Wasm > Wasm to bytecode.
b34r 4y ago
Good luck getting browser support so it’s actually usable
- detaro 4y ago
  Software that doesn't run in the browser actually still exists. A format doesn't have to take over the world and all use cases to be good.
- a2800276 4y ago
  I could conceivably see a use for this in contrainted devices, i.e. embedded with small, low resolution displays. It sees to be missing text rendering entirely, though.
deleted 4y ago
[deleted]
specialist 4y ago
Nice. I like how styles are defined up top and referenced thereafter. Maybe modify the header from 'lisp' to a shebang, like: #!tinyvg
osswannabe 4y ago
Disclaimer: dumb questions ahead. 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?
- TUSF 4y ago
  As far as I understand, it's more geared towards embedded systems, game ui, and gui icons. Places where a full SVG renderer is absolutely overkill. I think they see the tooling being used to create SVGs as usual, but then converting those SVGs to the much more stripped down format of tvg.
teaearlgraycold 4y ago
IMO binary encoded versions of files that are already small are more hassle than they'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. 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.

345 points by tsujp 4y ago

If we ZIP both SVG and TVG, the difference is not that large anymore. 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.

scythe 4y ago
I don't think the size is a key advantage here, even if it were true. 96 kilobytes simply isn't very big to start with, considering most of the content that gets sent around. 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.
- IvanK_net 4y ago
  If someone already implemented an XML parser for you, SVG is easier to implement than TVG (if you are trying to extract the same type of content out of SVG as out of TVG).
  - scythe 4y ago
    >if you are trying to extract the same type of content out of SVG as out of TVG 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.

DeathArrow 4y ago

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

jansan 4y ago
Probably not, because it is just a file format, which does not specify how things are rendered. 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.
TUSF 4y ago
Its simpler format should make it faster to parse & decode, at least. Whether that might affect render times is likely to depend on the renderer itself.

lalaithion 4y ago

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

veqq 4y ago

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

est 4y ago

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

Narishma 4y ago
Are those open formats?

winter_blue 4y ago

This looks pretty impressive. They've got an official specification up at: https://github.com/TinyVG/specification https://github.com/TinyVG/specification Also, interestingly, it's written in Zig: https://github.com/TinyVG/sdk https://github.com/TinyVG/sdk

FreeTrade 4y ago

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.

Dalewyn 4y ago

I'm going to sound like Richard Stallman, but being human-readable and Notepad-accessible is a huge advantage for SVG compared to this and its binary nature.

ianburrell 4y ago
I think there is a place for rich text and compact binary formats. Then can pre-render from complicated source to produce smaller and faster binary format. You would edit the SVG and then make TinyVG (and minified SVG). SVG is weird among image format in that it is XML. It requires a lot of effort to parse and render.
detrites 4y ago
You may have missed that it has both a binary and a text version.
- montag 4y ago
  Yes, but the text version is "not required to be implemented by conforming implementations". The wrong tradeoff, in my opinion.
  - detrites 4y ago
    It's optional, so if the need you identified exists it will be implemented. Its essential selling-point is compactness, so being the target, the path of least resistance should be optionally allowing the text-form, not building around it.
rcoveson 4y ago
What does "Notepad-accessible" mean? Surely you're not referring to notepad.exe in a sentence beginning with "I'm going to sound like Richard Stallman"?

angelmm 4y ago

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. 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.

easrng 4y ago
idk i export SVGs from inkscape and edit them by hand pretty frequently, it's not that hard.
- angelmm 4y ago
  For me most changes are related to colors and text. Paths are quite difficult to edit.
  - easrng 4y ago
    oh yeah i don't edit paths by hand, just stuff like cleaning up groups, removing unused css, changing colors, etc. when i do need to edit paths i use https://yqnn.github.io/svg-path-editor/ https://yqnn.github.io/svg-path-editor/

abdellah123 4y ago

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

geokon 4y ago

"SVG is a horribly complex format and an overkill for most projects" 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?

fbdab103 4y ago
Just casually browsing the SVG spec[0] looks like it covers a lot of ground. Different coordinate systems, CSS styling, paths, clipping, filters, animations, scripting, fonts etc. There needs to be an open vector format that supports all of those things, but maybe it is inappropriate that this is what get shipped by default. [0]: https://www.w3.org/Graphics/SVG/1.1/ https://www.w3.org/Graphics/SVG/1.1/
- easrng 4y ago
  tf are you on, paths and clipping are essential.
- gardaani 4y ago
  SVG Native was supposed to fix that [1]. SVG Native uses only one coordinate system, no CSS styling, no filters, no animation, no scripting and no text or fonts. However, it didn't get much interest and it's starting to look like a dead version of SVG. Maybe there isn't any need for a simpler vector graphics format because no one is using TinyVG, either. [1] https://w3c.github.io/svgwg/specs/svg-native/index.html https://w3c.github.io/svgwg/specs/svg-native/index.html
  - geokon 4y ago
    “SVG Native is a subset of SVG 1.1, which removes animation, interactivity, linking, remote resource loading, scripting, and CSS ” 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..

archfrog 4y ago

Three cheers!!! 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!

fbdab103 4y ago
If we are really talking wish lists, I dream of a simplified PDF spec.
- signaru 4y ago
  Also a simplified font spec while we're at it? While there are libraries for it, it is apparently discouraging if you wanted to code your own parser for the existing font formats.
- john61 4y ago
  Postscript?
  - mkl 4y ago
    Unlike PDF, PostScript is a full Turing-complete programming language, capable of far more document complexity than PDF (though less interactivity). The PostScript Language Reference Manual is 900 pages, and the PostScript Language Reference Supplement is another 160.
    - 4y ago

gardaani 4y ago

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

ot 4y ago

The author would make an even stronger case if they showed the results after compression. On the few examples in the home page, which I compressed with gzip -9 (zstd performs similarly): 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 In most cases, even after gzip compression TVG still has a substantial lead over SVG. 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.

dolmen 4y ago
I see much more gain in TinyVG in CPU usage to decode and render an image. XML is definitely not the most efficient way to expose data that is not meant for human consumption.
- Mikhail_Edoshin 4y ago
  XML, of course, is an opposite: It is a rather good way for humans to create data meant for computer consumption. Once the data are laid out, they can be transformed into a more efficient machine form in the same way a program is compiled, but for the web this is rarely done for any format, including pure machine-to-machine interaction. E.g. JSON is mostly used for machine-to-machine exchange and it is far from begin efficient for this.
- i-use-nixos-btw 4y ago
  That would be what I’d care about the most. Smaller file size, but not an order of magnitude difference? Meh. 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.

deleted 4y ago

[deleted]

giomasce 4y ago

What features does it miss from SVG?

nomercy400 4y ago

What part of SVG does TinyVG NOT support? 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.

progx 4y ago

Senseless, if you not explain what will work with TinyVG and what will not work. 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.

iainmerrick 4y ago
Those sound like missing features in the importer rather than an actual gap in the spec. Transforms and different color spaces could be baked into the data at import time.
- deleted 4y ago
  [deleted]

oefrha 4y ago

By far the biggest advantage of SVG on the web is DOM integration, thanks to its choice of XML. This enables, among other things, - 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.

rendaw 4y ago
SVG is firewalled off from js and css regardless of how you use it. The only way to practically interact with SVG content (i.e. make it actually more useful than a jpg) you need to embed it directly, which requires stripping the `<?xml` and `<!DOCTYPE`, which requires an xml parser/serializer. 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.
- oefrha 4y ago
  > you need to embed it directly. 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.
  - IshKebab 4y ago
    > Guess what "DOM integration" means. Does it mean unusably inconvenient? Because that's what I call having to embed SVGs just so CSS works with them.
    - ttfkam 4y ago
      Hold up. Are you blaming SVG because you don't know the <object> tag exists? I mean, yeah, you're right that CSS won't come through with an <img> tag. It will with <object> though. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/object https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ob...

ar9av 4y ago

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

gardaani 4y ago
Google also has Vector Drawables for Android [1]. I'm sure they'll also create the other 12 competing successors, because each of their platforms need a new separate format. [1] https://developer.android.com/develop/ui/views/graphics/vector-drawable-resources https://developer.android.com/develop/ui/views/graphics/vect...
- droidist2 4y ago
  Facebook/Meta will create a 15th standard; people will decry it for not following one of the previous 14 standards, but everyone will adopt it. Then Google will re-release one of their 14 but change everything to look more like Meta's.
AnIdiotOnTheNet 4y ago
Too late. Here's another one: https://en.wikipedia.org/wiki/Haiku_Vector_Icon_Format https://en.wikipedia.org/wiki/Haiku_Vector_Icon_Format
- kevin_thibedeau 4y ago
  HVIF isn't general purpose. It's solely focused on icons and sacrifices precision for the sake of more compact encoding.

deleted 4y ago

[deleted]

al_be_back 4y ago

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

edflsafoiewq 4y ago
At that end it competes against compiling your graphic directly to source code, eg void draw_tiger(ctx) { ctx.setFillColor(255, 255, 255); ctx.beginPath(); ctx.moveTo(124, 56); // etc }

iainmerrick 4y ago

I want to like this more, but it doesn't seem very compelling. 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 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.

edflsafoiewq 4y ago
> Only sRGB colors are supported -- why not linear? 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.

dang 4y ago

Related: TinyVG: A challenger to the throne of vector graphics - https://news.ycombinator.com/item?id=29629792 https://news.ycombinator.com/item?id=29629792 - Dec 2021 (187 comments)

nabla9 4y ago

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

ha1zum 4y ago

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

Pxtl 4y ago

A lot of people are defending SVG by pointing out how it integrates with CSS and JS the DOM and I'm like "yes that's why a simpler format is better". SVG is too powerful to use as a simple image format. 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.

Dork1234 4y ago

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

1-6 4y ago

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

userbinator 4y ago

There'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. 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.

mcdonje 4y ago
SWF is flash. Vector graphics are just a subset of the format. Any tool claiming to support that format would have to support the rest of the spec, which is overkill for many vector applications. Even though Adobe owns SWF, they don't support it in Illustrator outside of exporting.
- userbinator 4y ago
  Plenty of existing tools only support a subset of SWF, mainly the vector graphics and animation parts. It's used for UIs in games and various other applications. https://en.wikipedia.org/wiki/Gameswf https://en.wikipedia.org/wiki/Gameswf
- account42 4y ago
  You can always pull a marketing stunt like .webm vs. Matroska if you want to advertise support for a variant of Flash constrained to just the vector parts.
Narishma 4y ago
Is there a spec for SWF?
- robterrell 4y ago
  https://open-flash.github.io/mirrors/swf-spec-19.pdf https://open-flash.github.io/mirrors/swf-spec-19.pdf

bigattichouse 4y ago

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 > Wasm > Wasm to bytecode.

b34r 4y ago

Good luck getting browser support so it’s actually usable

detaro 4y ago
Software that doesn't run in the browser actually still exists. A format doesn't have to take over the world and all use cases to be good.
a2800276 4y ago
I could conceivably see a use for this in contrainted devices, i.e. embedded with small, low resolution displays. It sees to be missing text rendering entirely, though.

deleted 4y ago

[deleted]

specialist 4y ago

Nice. I like how styles are defined up top and referenced thereafter. Maybe modify the header from 'lisp' to a shebang, like: #!tinyvg

osswannabe 4y ago

Disclaimer: dumb questions ahead. 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?

TUSF 4y ago
As far as I understand, it's more geared towards embedded systems, game ui, and gui icons. Places where a full SVG renderer is absolutely overkill. I think they see the tooling being used to create SVGs as usual, but then converting those SVGs to the much more stripped down format of tvg.

teaearlgraycold 4y ago

IMO binary encoded versions of files that are already small are more hassle than they'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. 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.