Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TinyVG: A challenger to the throne of vector graphics

zig.news

Post reply on HN
Print view View original

81–90 of 196 posts

Re: TinyVG: A challenger to the throne of vector graphics

#81

Post by ikskuh »

CamperBob2 wrote: post #80

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…

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

Re: TinyVG: A challenger to the throne of vector graphics

#82

Post by userbinator »

mdswanson wrote: post #63
userbinator wrote: post #47

I wondered how it compares to the same subset of SWF, which is another vector format designed with a huge emphasis on size and decode efficiency. The example tiger.svg is 96719, and tiger.tvg is 27522, but I have a tiger.swf which is 21381 and tiger.pdf 77377. It seems to be a little worse than SWF, but much better than SVG and PDF. I agree with the author that SVG is bloated, but not sure making another format is th…

SWF is more of a painters/immediate-mode model and SVG/PDF/etc. is a retained mode that defines a set of objects. Different use cases for sure. I've written SWF->vector conversion tools, and the formats are quite different.

You can define sprites in SWF too.

Re: TinyVG: A challenger to the throne of vector graphics

#83

Post by tdeck »

jabbany wrote: post #52
pcwalton wrote: post #7

There are many other popular vector graphics formats beyond those mentioned here. Lottie has already displaced SVG for animation/motion graphics, and for static content IconVG exists and is backed by Google. There's also PDF, PostScript, Flash, the glyf format in OpenType, etc.

Franky somebody should do like a TinyDF replacement for pdf... That's also a somewhat bloated format at this point. Ideally though, the tiny* formats should be forward compatible (?) and interpretable as a valid non-Tiny* document. That would be quite nice for wider adoption (like JSON).

"somewhat bloated" is the understatement of the century. PDF documents can contain executable code in two different programming languages (JavaScript and PostScript), interactive content, digital signatures, their own form of encryption, and more. Why they thought adding JavaScript to an already infamous attack vector of a format is beyond my understanding.

Re: TinyVG: A challenger to the throne of vector graphics

#84

Post by adgjlsfhk1 »

shatteredgate wrote: post #54
adgjlsfhk1 wrote: post #46

Earlier quoted context omitted.

XML is bad because it bloats the size by roughly 3x (compared to other text formats like s-exprs), is difficult to implement properly. HTML is bad too, we're just more stuck with it so it's less useful to complain.

The size is not really an issue for any compression algorithm. I've seen quite a few small XML parsers that don't bother with the full spec and only implement a subset.

Even when you compress XML, it's still around 10% bigger than JSON, and around 40% bigger than protobuf (not endorsing either, just examples). Furthermore, making the compressor work harder isn't free. The time to compress and decompress XML is roughly 2x higher than with JSON, and if you decompress the data before using it, XML will still hit you wrt RAM usage.

All of these would be fine if XML offered you some really good advantage over alternatives, but as far as I can see, it doesn't. It just eats up CPU/memory/bandwith/keystrokes for no reason.

Re: TinyVG: A challenger to the throne of vector graphics

#85

Post by sysrpl »

I am not sure how relevant this is, but I recently published a proof a concept library that converts SVG documents into simulated machines. See the link below.

https://www.getlazarus.org/videos/physics/blueprint/

The rendering in my library relies upon OpenGL and the NanoVG library. My library is called Tiny Sim. All of these nano tiny and vg names seem to be colliding adding a bit of confusion in my opinion.

Re: TinyVG: A challenger to the throne of vector graphics

#86

Post by dnautics »

shatteredgate wrote: post #51
dnautics wrote: post #48

Earlier quoted context omitted.

seriously, it shouldn't be so hard to write a parser that compiles your favorite text format to TVG, or even to the lispy text format.

IMO that defeats the purpose of using this format if you have to write things to compile to it. If you do that you might as well just compile to the binary format since you won't be editing your canonical representation anyway. I'd imagine with image formats you'd want to pick a format that is the easiest possible thing to parse and consume while not harming it's "editableness" and I don't think S-expressions fit tha…

Tvg is a binary format? It's not really human readable. Compiling to it is a natural thing to be doing.

Re: TinyVG: A challenger to the throne of vector graphics

#87

Post by culi »

sysrpl wrote: post #85

I am not sure how relevant this is, but I recently published a proof a concept library that converts SVG documents into simulated machines. See the link below. https://www.getlazarus.org/videos/physics/blueprint/ The rendering in my library relies upon OpenGL and the NanoVG library. My library is called Tiny Sim. All of these nano tiny and vg names seem to be colliding adding a bit of confusion in my opinion.

This is actually just like... aesthetically pleasing to watch. As someone who loves watching/reading about Game of Life lifeforms, I'd love to see some sort of gallery where people can share their creations and/or build upon other people's

Re: TinyVG: A challenger to the throne of vector graphics

#88

Post by shatteredgate »

templix wrote: post #75
shatteredgate wrote: post #45

Earlier quoted context omitted.

Am I the only one who dislikes S-expressions and prefers XML or JSON or even YAML? The parenthesis are way too confusing when editing manually and the format doesn't have enough semantic information to always correctly parse into common structures in any language besides lisp. I enjoy writing lisp myself but I really think it is a mistake to use them for common formats everywhere that I've seen it tried.

You enjoy writing Lisp, but somehow find parenthesis way too confusing when editing manually? That's pretty hilarious. If you take the expression above and format it in any half-decent editor, it's pretty clear. YAML is a shitshow, JSON is yuck and let's not talk about XML.

Yes, I enjoy lisp the language and its constructs but I don't enjoy the parenthesis or the syntax. What's hilarious about that? I'm sure you could list some aspects of lisp that you don't like if you have a lot of experience with it.

>YAML is a shitshow, JSON is yuck and let's not talk about XML.

My issue with S-expressions as a data exchange format is that they're actually just the worst aspects of all three of those combined. If you're frustrated by XML having really deep trees and only having strings and elements as datatypes, then S-expressions are just as bad, reliably they only really have strings and lists as datatypes and the trees tend to have even deeper nesting than XML. For JSON the formats are equivalent if you remove everything from JSON except lists and strings, so S-expressions are strictly a worse subset, they're just as yuck. YAML is bad because it's complex and badly specified but S-expressions are still worse of a shitshow because there is no spec. You just have to hope the format you used is compatible with your Lisp implementation. And yes this has caused me problems where using "read" on S-expressions with certain characters in them or in certain encodings completely breaks on some Lisp implementations. If you're using some other language that isn't Lisp and you're rolling your own parser then good luck having that be compatible with anything, most parsers I see just pick a random Lisp implementation and aim for compatibility with it which is still not reliable.

The only good thing I can say about S-expressions is that they're quite easy to spit out from a bash script, but for this problem domain (vector graphics) there is an even easier option: use a very simple command-based format like postscript.

Re: TinyVG: A challenger to the throne of vector graphics

#90

Post by FractalHQ »

pcwalton wrote: post #24
nigeltao wrote: post #21

Earlier quoted context omitted.

IconVG author here. Happy to discuss. Animation is issue #2 on https://github.com/google/iconvg and I have some ideas but no code yet. I'm also midway through changing the current "version 0" format into a "version 1" format, dropping things like the ArcTo op (inspired by SVG) precisely with one eye on (future) animation support. The ArcTo large-arc-flag, like any boolean-typed value, is impossible to interpolate smo…

IMO as long as animation isn't tied to After Effects like Lottie is, you can't go wrong. The fact that the most popular open vector animation format is tied to an expensive, proprietary piece of software that isn't even primarily a vector art package makes me very sad…

Not to mention After Effects is an extremely poorly performing and highly bloated piece of software tied to mountains of spyware… It’s almost impressive how bad the software is by modern standards.
Post reply on HN