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

71–80 of 196 posts

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

#71

Post by templix »

jancsika wrote: post #55

> 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…

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

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

#72

Post by akdor1154 »

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.

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

#73

Post by hutzlibu »

db65edfc7996 wrote: post #67
hutzlibu wrote: post #27

Earlier quoted context omitted.

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.

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.

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

#74

Post by ikskuh »

pier25 wrote: post #61

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

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

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

#75

Post by templix »

shatteredgate wrote: post #45
ikskuh wrote: post #26

Earlier quoted context omitted.

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

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.

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

#77

Post by ikskuh »

akdor1154 wrote: post #72

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 choice…

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

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

#79

Post by xienze »

exabrial wrote: post #43
ikskuh wrote: post #22

Earlier quoted context omitted.

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…

"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" 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.

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

#80

Post by CamperBob2 »

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 adopt one of the existing lightweight renderers, forking it if necessary.

As others have pointed out, representation size doesn't matter because it'll be compressed anyway in any applications where size is important. Plain old text is fine.

Post reply on HN