What about performance? I assume a TinyVG decoder will be much faster than an SVG one.
I expected to see something related to performance in the benchmark[1] but it's only focused on file size.
TinyVG: A challenger to the throne of vector graphics
61–70 of 196 posts
Re: TinyVG: A challenger to the throne of vector graphics
#62Earlier quoted context omitted.
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…
The tag thingy is an interesting idea, could you create a github issue on the specification repo for that?
Re: TinyVG: A challenger to the throne of vector graphics
#63I 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.
Re: TinyVG: A challenger to the throne of vector graphics
#64Excluding 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 .
Can't you use the animate method on them at this point?
E.g., even in Firefox I can do myRect.animate([ { x: "0px" }, { x: "100px" }], 1000); and it works correctly.
Re: TinyVG: A challenger to the throne of vector graphics
#65> How will this look in different browsers? Let's test! obviously different font widths for rendering of SVG text in different browsers/font stacks > That didn't go as expected. I thought that at least both files on my Linux machine look the same, but it seems like Firefox doesn't like the font-size specification, while Chrome and Edge do. I asked the Render-A-Webpage-As-An-SVG-framework guy about this last week. He…
That's a good question! I fell for this problem with text rendering once as the font i've used in a SVG wasn't installed on the target machine.
If i create a image, i want that image to look exactly the same on all machines. This is sadly not the fact for SVG :(
The W3C SVG example files contain a lot of these files that make every SVG renderer explode. There's images that don't render anywhere except inkscape
Re: TinyVG: A challenger to the throne of vector graphics
#66There 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?
EPS is just PostScript that's designed to be more embeddable. It's a PostScript program that contains some metadata like a preview image (so you can display a thumbnail when embedding it even if you don't have a PS interpreter) and a bounding box (since PS has an arbitrary coordinate system, in order to represent an embedded document without actually interpreting it, you need to know the bounds of what it's going to draw).
The big problem with PS, EPS and Flash as simple graphics formats is that they're all turing complete and you can author documents that will never terminate. When importing EPS, Illustrator used to have a timeout and would fail if the render didn't complete in a couple minutes. I assume it still does, but haven't tried it in years.
Re: TinyVG: A challenger to the throne of vector graphics
#67Earlier quoted context omitted.
> 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.
GIFs are horrible in terms of memory. Java applets died out of technical reasons (and was replaced by flash) Flash died, because it was proprietary and Adobe did not open it up. (and flash was vector animation btw.) Otherwise it surely would still be around. And in a way it is, as you can export flash animations to the html canvas element. And some people do that (with quirks) In other words, a simple, but powerful v…
>Flash died, because it was proprietary and Adobe did not open it up. (and flash was vector animation btw.)
I think the iPhone refusing to support Flash had far more to do than the underlying business practices or IP.
Re: TinyVG: A challenger to the throne of vector graphics
#68I 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…
Yeah, SWF looked promising in its day and its a shame it is basically dead(?)
Re: TinyVG: A challenger to the throne of vector graphics
#69Tiny differences? Shits blurry as hell.
Re: TinyVG: A challenger to the throne of vector graphics
#70Earlier quoted context omitted.
"XML is bad" is still one of the worst engineering arguments. Why is it bad? What is the tradeoff? Things that are bad are easy to quantify as they're measurable. What does it have? It has strong schema support built in. Any intelligent IDE allows for cmd-space completion by reading the XSD. I don't buy this argument as full XML parsers are not even as complicated as HTML5 parsers, which nobody seems to have an issue…
XML is bad for TinyVG as it is too large in several regards. XML kinda requires DOM parsing, XML is a text format (so inefficient encoding) and XML parsers need to be large so they can be called XML parsers. All of these properties contradict a embedded world where you can render vector graphics from 32k RAM on a chip that doesn't even have enough memory for a framebuffer itself. Also implementation complexity of XML…
I agree that SVG/XML is bad for embedded and I think this format is cool but you probably can agree it's unlikely anything will displace SVG unless it matches it in features, one of the benefits which is to manipulate SVGs using the DOM in browsers.