Live data from Hacker News

TinyVG: A challenger to the throne of vector graphics

zig.news

31–40 of 196 posts

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

#31
post #9

Excluding animations kills this for me . We need more SVG animations on the web. But the state of animation in SVG is a headache unless your using a third party library .

> We need more SVG animations on the web. Do we, though? We've already had animated GIFs, the marquee tag, Java applets, and Flash animation, and they've all died out because 99.9% of the time the animation is obnoxious and terrible. Vector animation would be just as annoying.

Flash animation didn't die out--it was assassinated by Steve Jobs.

Flash renderers didn't have to suck. However, there wasn't enough money in it for anyone to care.

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

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

I have heard very good words about the eps format from a vector-format nerd (he reads file format specifikation books because its fun). I would love to here more opinions about eps from other developers. How does eps really compare with the other formats mentioned above?

I've been avoiding EPS like the plague for several decades. Unless something has changed since I last looked it would be well below SVG on my preferred format list.

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

#33
post #9

Excluding animations kills this for me . We need more SVG animations on the web. But the state of animation in SVG is a headache unless your using a third party library .

> We need more SVG animations on the web. Do we, though? We've already had animated GIFs, the marquee tag, Java applets, and Flash animation, and they've all died out because 99.9% of the time the animation is obnoxious and terrible. Vector animation would be just as annoying.

> Do we, though?

We do definitely need better vector graphics, including animations. Because then you can have the same crisp images and animations regardless of your resolution or screen size.

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

#34
post #25
post #9

Excluding animations kills this for me . We need more SVG animations on the web. But the state of animation in SVG is a headache unless your using a third party library .

TinyVG is not meant to ever support animations, but should be used in all places where this is not required. So if you want to use animation for everything, you could design a secondary format that allows animation of TinyVG files hint

the biggest thing we could get for the standard that would really help people to animate TinyVG files via a secondary format, without animating TinyVG files, is if you can tag an item with a reference. Maybe do commands 17-26, which are (command n - 16) + an optional 32-bit "reference" field on the top. References are basically "up to the implementor" to do whatever they want with. You might want to also do a command "16" which is an optional "group separator", followed by a 32-bit reference that is otherwise ignored by the TVG engine.

You could probably take a hard line that once you have references, there is no need for any other extension, those are doable using references.

BTW, has someone worked on a js backfill that lets you load the file format in an image tag? I'd be happy to give it a shot with zig/wasm.

Edit: OK, I just found the polyfill.

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

#35
post #22

While I do appreciate the thought process and hard work, it does maybe feel like the most of the benefits could be obtained with a strict subset of SVG instead - something like SVG Tiny was meant to be, but with fewer bad decisions! That would allow for compatibility with the existing ubiquitous SVG ecosystem.

The problem with that is that you still need to implement a full XML parser. Even if you strip out any CSS and ECMAScript, it will still require the complexity of XML with all it's gloryness and escapiness and ambigious defines. And even if we rely only on XML, we get the DOM and hierarchical structures. If we forbid those, we have as a file format and people will look weird because their other SVG won't be supported…

You could also restrict the allowed XML so it can be parsed/generated without a full parser.

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

#37
post #18

For simple image generation, nothing beats SVG or EPS. For years, these two technologies have let me add cool stuff to PDFs and web pages without the need for expensive/complex/insecure libraries. It is going to be pretty hard to beat the ease of generating these formats.

Agreed; I was playing with pinwheel tilings [1] today and decided to make some pinwheel art [2] that fits in a signature:

    %!PS                           % -John Tromp http://tromp.github.io/
    /t{dup 1 sub gsave dup 0 gt{[.4 .2 -.2 .4 .4 .2]concat t currentgray
    .8 mul .2 add setgray -1 1 scale t -1 2 translate t 1 -1 scale t[0 1
    1 0 0 2]concat t pop}{0 moveto 1 0 lineto 0 2 lineto closepath clip
    fill}ifelse grestore}def 10 10 translate 600 600 scale 5 t showpage

[1] https://en.wikipedia.org/wiki/Pinwheel_tiling

[2] https://tromp.github.io/img/pinwheel.pdf

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

#39
post #14

Earlier quoted context omitted.

Yes, i've heard it from some people already. Will add this to the benchmark tomorrow. It's late here in germany and running the benchmark takes roughly 30 minutes already. With gzip, i expect it to go up to 45 or 60 minutes, as we all want good compression rates!

Also is the svg itself optimized? Usually possible to take a lot off them with tool like svgomg: https://jakearchibald.github.io/svgomg/

or Nano

https://vecta.io/blog/how-nano-compresses-svg/

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

#40
post #14

Earlier quoted context omitted.

Yes, i've heard it from some people already. Will add this to the benchmark tomorrow. It's late here in germany and running the benchmark takes roughly 30 minutes already. With gzip, i expect it to go up to 45 or 60 minutes, as we all want good compression rates!

Also is the svg itself optimized? Usually possible to take a lot off them with tool like svgomg: https://jakearchibald.github.io/svgomg/

I have a full description of the benchmarking process on https://tinyvg.tech/benchmark.htm

tl;dr: The input svg is pushed through svgo, so we have a very compact format already

Post reply on HN