TinyVG: A challenger to the throne of vector graphics

Re:TinyVG: A challenger to the throne of vector graphics by ikskuh on Monday December 20, 2021 @05:24PM (#29631179)

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 is so high that i gave up on impementing a correct parser. I don't want to have a half-assed parser that cannot parse XML, but only "XML light" and making this is a huge amount of work which i don't want to waste in my leisure time

[ Parent | on HN ]

Re:TinyVG: A challenger to the throne of vector graphics by shatteredgate on Monday December 20, 2021 @05:45PM (#29631454)

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.

[ Parent | on HN ]

Re:TinyVG: A challenger to the throne of vector graphics by dragonwriter on Monday December 20, 2021 @11:36PM (#29633937)

> XML kinda requires DOM parsing

Why? Streaming/evented (e.g., SAX) parsing for XML is as old as XML.

[ Parent | on HN ]

Re:TinyVG: A challenger to the throne of vector graphics by ikskuh on Tuesday December 21, 2021 @03:23AM (#29635205)

Yes, but SVG can and will do forward references. Ergo, we have to store some kind of DOM in order to resolve them. Even if it's not in the form of the XML doc

[ Parent | on HN ]

Re:TinyVG: A challenger to the throne of vector graphics by int_19h on Wednesday December 22, 2021 @01:13AM (#29646073)

Couldn't the proposed subset just drop forward references?

[ Parent | on HN ]