[HN Gopher] TinyVG: A challenger to the throne of vector graphics
___________________________________________________________________
TinyVG: A challenger to the throne of vector graphics
Author : todsacerdoti
Score : 170 points
Date : 2021-12-20 20:22 UTC (2 hours ago)
(HTM) web link (zig.news)
(TXT) w3m dump (zig.news)
| BudaDude wrote:
| 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 .
| ikskuh wrote:
| 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_
| dnautics wrote:
| 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.
| ikskuh wrote:
| The tag thingy is an interesting idea, could you create a
| github issue on the specification repo for that?
|
| => https://github.com/TinyVG/specification/
| jancsika wrote:
| 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.
| [deleted]
| MisterBiggs wrote:
| If your argument is that animations in SVG don't work well then
| wouldn't it be best to use TinyVG in place of static SVG assets
| and make something new that is better suited for animation?
| jlarocco wrote:
| > 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.
| hutzlibu wrote:
| 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 vector animation tool,
| is very much needed. The current state is a mess.
|
| And you probably do not like vector animated advertisement,
| or websites that use animations for the sake of animations.
| Sure, no one wants that.
|
| But how about games, or interactive graphic to for example
| show complex data in context to some map? Or animations for
| didactic purposes? Cartoons?
|
| A animation well done is actually one, you do not notice.
| (but you would notice, if it was missing)
| db65edfc7996 wrote:
| >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.
| hutzlibu wrote:
| Well, to me that is the same thing, because since it was
| proprietary, Steve Jobs and Apple could not control it
| (and maybe improve it and adopt to their standards) - so
| they rather threw it out. (not that apple had a problem
| with proprietary tools, justs with proprietary tools not
| under their control, in a vital position)
|
| If the Flash player would have been open in a way,
| chromium/webkit is, with many top players working on it -
| it very likely would still be around and maybe even
| dominating, as it was way superior in terms of features
| and more importantly, it was not a mess to work with,
| like HTML still is.
| __m wrote:
| That's a bit revisionist history. Flash was pretty popular
| and animations haven't gone away.
| sigg3 wrote:
| <marquee>Bring Me Back!!</marquee>
| pcmaffey wrote:
| For some tasteful svg animation examples, check out my blog
| articles.
|
| [1] https://www.pcmaffey.com
| bsder wrote:
| 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.
| dmitriid wrote:
| > 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.
| cryo wrote:
| This looks interesting. Small issue, the link to the SDK manual
| currently throws a 404:
|
| https://tinyvg.tech/download/tinyvg-sdk-readme.txt
| ikskuh wrote:
| whoopsies. CI failure on my side, will be fixed in roughly 20
| minutes
| goodmachine wrote:
| what's wrong with SVGTiny?
|
| https://www.w3.org/TR/SVGTiny12/index.html
| CamperBob2 wrote:
| 90+% of real-world SVG files render just fine with NanoSVG, so
| I don't really see any point in SVGTiny or any other formats.
| Just define a subset of SVG that supports the features commonly
| in use, and give it a name.
|
| As others have pointed out, representation size doesn't matter
| because it'll be compressed anyway.
| the_duke wrote:
| If you take a look at the spec you will find:
|
| 12 Multimedia, 13 Interactivity, 14 Linking, 15 Scripting, 16
| Animation, 17 Fonts
|
| That does not sound very tiny to me.
| fsgghjhgfd wrote:
| jancsika wrote:
| > 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 claimed over multiple years he hasn't had a
| _single_ report of broken text rendering from users of his
| framework.
|
| So what's the deal? Are OP and me the _only_ devs who have ever
| hit up against this issue in practice?
| ikskuh wrote:
| 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
| [deleted]
| templix wrote:
| > So what's the deal? Are OP and me the only devs who have ever
| hit up against this issue in practice?
|
| The sad truth is that many issues go unreported because people
| are lazy and move on when they hit a roadblock.
|
| Also, I've seen this problem reported more than a few times so
| you're not alone.
| losvedir wrote:
| Very interesting! I like the idea. One sort of concerning thing
| is in the comparison chart on the page, the middle column (the
| TinyVG renderer) the images look a little blurry to me. Is that
| just a limitation of the renderer? I suppose since the right
| column is clear, it means the spec is _capable_ of producing
| clear images, right?
| ikskuh wrote:
| Author here:
|
| This is actually a limitation of chrome! The images are
| perfectly sharp when displayed as files:
|
| https://tinyvg.tech/img/app-icon.png
|
| The are just up/downscaled to 3em height so the table looks
| uniform
| adgjlsfhk1 wrote:
| I'm seeing the same thing in firefox (Linux)
| ikskuh wrote:
| Yes, it's because the images in the PDF are always scaled.
| I cannot get them to pixel-perfect display in the PDF
| renderings anyways
|
| The images are the output from the offline renderer, so
| they are included as PNGs
| styfle wrote:
| Looks really interesting!
|
| Can TinyVG be converted to other image formats, such as PNG?
| ikskuh wrote:
| Yes, the SDK contains tvg-render which can render TVG to TGA.
| Implementing PNG in that tool would double the size of the SDK
| source ^^
| userbinator wrote:
| 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 the answer, especially when
| there's already very good prior art.
|
| (I have written SWF rendering and conversion code before, so I
| might be biased in saying that it's an example of a very well-
| designed vector format; too bad Adobe has been trying to kill it
| off.)
| hutzlibu wrote:
| Yeah, SWF looked promising in its day and its a shame it is
| basically dead(?)
| mdswanson wrote:
| 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.
| 28uwedj wrote:
| Tiny differences? Shits blurry as hell.
| flohofwoe wrote:
| Looks crisp here on a 14"MBP (this demo:
| https://tinyvg.tech/polyfill/index.htm)
| ComputerGuru wrote:
| Really cool work - I've been looking for something like this for
| some time and have played around with HVIF and IVG to that end.
|
| @ikskuh since I see you here in the comments, I have one nitpick:
| I don't think it's fair to compare your binary format to an
| _uncompressed_ SVG file since they are most often used online
| (and often used even offline) as gzip- or brotli-compressed
| resources. It would be nice to see an additional comparison
| between gzipped TinyVG and gzipped SVG to help even the playing
| field.
| ikskuh wrote:
| 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!
| ShrigmaMale wrote:
| Also is the svg itself optimized? Usually possible to take a
| lot off them with tool like svgomg:
| https://jakearchibald.github.io/svgomg/
| goodmachine wrote:
| or Nano
|
| https://vecta.io/blog/how-nano-compresses-svg/
| ikskuh wrote:
| 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
| pier25 wrote:
| 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.
|
| [1] https://tinyvg.tech/benchmark.htm
| ikskuh wrote:
| The question is if we talk about decoding or rendering
| performance. Right now, the software renderer is slow as heck
| and not optimized at all.
|
| But the decoding speed should be blazingly fast, as there is
| not much memory heavy lifting to do, and only a handful of int
| to float conversions.
|
| As soon as i have a competetive rendering (aka Vulkan), i will
| add those to the benchmark. My guess is that rendering TinyVG
| should also be much faster than SVG due to not having any
| matrix transformations or hierarchies included in the format
| pupppet wrote:
| I have to install a plugin to allow my WP sites to support SVG
| because they can potentially contain scripting, what a pain in
| the ass. All we wanted was vector images, what we got was vector
| images and a couple kitchen sinks. Bring on the alternatives.
| ARandomerDude wrote:
| Also, don't use WordPress. It sucks.
| jancsika wrote:
| FYI-- if a user right clicks to "View Image" on an SVG, the new
| tab will run any scripts contained in the SVG.
| mmcgaha wrote:
| 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.
| tromp wrote:
| 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
| mmcgaha wrote:
| Lovely example! Beautiful postscript makes me warm and fuzzy
| inside.
| ikskuh wrote:
| Then you should check out the TinyVG text format:
|
| (tvg 1 (32 32 1/1 u8888 reduced) ( (1 0 0) ) ( (fill_polygon
| (flat 0) ( (16 0) (32 32) (0 32) )) ) )
|
| This draws you a tiny triangle. The only problem you'll get is
| when doing text, but for SVG: These wouldn't be portable
| anyways
| shatteredgate wrote:
| 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.
| templix wrote:
| 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.
| dnautics wrote:
| 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.
| shatteredgate wrote:
| 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 that bill.
| [deleted]
| matthewmacleod wrote:
| 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.
| ikskuh wrote:
| 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
| <svg><object /><object /><object /></svg> as a file format and
| people will look weird because their other SVG won't be
| supported in there.
| exabrial wrote:
| "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 with. It's not the end-all-be-all of formats, but this
| is something that's oft-repeated and never quantified.
|
| Your second point is actually valid though. If the TinyVG
| format takes advantage of non-tree based data-structures, I
| can certainly understand the motivation. I have a hard time
| conceptualizing how a tree based format would be beneficial
| to a vector format, other than describing metadata about
| certain "areas" of the image.
| xienze wrote:
| > "XML is bad" is still one of the worst engineering
| arguments.
|
| It's reached meme status. I think most people conflate
| complex XML-based _formats_ (e.g., WSDL, XSD) with XML _the
| format_. The rules of XML parsing can fit on a notecard.
| And a basic parser that supports all the core functionality
| plus namespaces is really not that complicated to
| implement. Now, implementing schema validation, Xlink, etc.
| in your parser is definitely not simple. But to make a
| simple XML parser those are optional bits.
| adgjlsfhk1 wrote:
| 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.
| shatteredgate wrote:
| 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.
| ikskuh wrote:
| 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
| shatteredgate wrote:
| 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.
| tracnar wrote:
| You could also restrict the allowed XML so it can be
| parsed/generated without a full parser.
| richardanaya wrote:
| Mesh gradients might make and impressive feature!
| ikskuh wrote:
| Can you elaborate that and provide some sources on what a mesh
| gradient is?
| pcwalton wrote:
| 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.
| nigeltao wrote:
| 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 smoothly.
| pcwalton wrote:
| 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...
| jabbany wrote:
| 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).
| dosshell wrote:
| 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?
| heleninboodler wrote:
| 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.
| andybak wrote:
| 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.
| IshKebab wrote:
| I can't imagine those good words ever came from anyone that
| has actually used it.
| HideousKojima wrote:
| The examples in his benchmark image are noticeably blurry
| compared to the SVGs. Is this due to his software renderer or
| something in the format itself? Because for me most of the reason
| I would use vector graphics in the first place is to maintain a
| crisp look regardless of resolution, and if the middle images are
| what I can expect from it then I definitely wouldn't use the
| format.
|
| Edit: Nevermind, this was answered in another comment, apparently
| it's a limitation of Chrome
| akdor1154 wrote:
| Huh, nice. I always reach for SVG when i want a hand-editable
| format for some random project, but your points on the parsing
| and implementation complexity seem very reasonable.
|
| Two qns: 1. Did you consider a re-specification of SVG or a
| subset in another embedding language that's easier to parse?
| text/json+svg, application/bson+svg, etc. (Examples for clarity,
| not literally suggesting json/bson are appropriate choices)
|
| 2. SVG has broken gamma-correct blending. It was originally not
| specified at all so all implementations did it wrong; i think the
| spec fixes it in 1.2 but the only people who care are Inkscape,
| and they explicitly aren't implementing it because they don't
| want to author files that in all likelihood will never display
| properly in browsers. So... the ship sailed in the wrong
| direction. Could be worth some thought at this early stage of
| your project, then you'd have a feature that you actually can't
| achieve in SVG.
| ikskuh wrote:
| > 2. ...
|
| Oh that explains why all my rendering experiments looked
| different from SVG. I think the reference renderer already does
| gamma correct blending.
|
| This is something we should add to the specification for sure.
|
| > 1. ...
|
| Even re-encoding the SVG crap would only remove XML from the
| equation, but that's not my main concern with SVG.
|
| Zig has the Zen "only one way to do things". Meanwhile SVG has
| tens of ways to solve the same problem.
|
| One example: You can set the opacity via css, fill-opacity and
| opacity. What you cannot do: Set the opacity via color. But you
| can make 50% black by _just_ specifying fill-opacity, as black
| is the default color. to render lines, you need to set fill to
| "none". ugh.
___________________________________________________________________
(page generated 2021-12-20 23:00 UTC)