TinyVG: A challenger to the throne of vector graphics

https://zig.news/xq/a-challenger-to-the-throne-of-vector-graphics-svg-is-dead-long-live-tinyvg-4on8

by todsacerdoti • 5 years ago

551 187 5 years ago

losvedir• 5 years ago

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?

ikskuh23• 5 years ago

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

adgjlsfhk13• 5 years ago

I'm seeing the same thing in firefox (Linux)

ComputerGuru• 5 years ago

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.

ikskuh23• 5 years ago

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• 5 years ago

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

pupppet• 5 years ago

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• 5 years ago

Also, don't use WordPress. It sucks.

anaganisk• 5 years ago

Wordpress itself doesn’t suck, its the plugin ecosystem developed by script kiddies that suck.

jancsika4• 5 years ago

FYI-- if a user right clicks to "View Image" on an SVG, the new tab will run any scripts contained in the SVG.

wongarsu• 5 years ago

SVG is basically HTML, but for graphics; with much the same ecosystem (JS, CSS, etc). In my opinion that's pretty awesome and opens a whole world of possibilities. At some point it looked like SVG was poised to become the successor of Flash, but the authoring site never appeared so we didn't get any successor to Flash.

Of course this has some drawbacks, particularly when talking about user-uploaded SVGs on a website (they probably shouldn't be on the same domain as the website at all). But that's a much narrower use case than what SVG was supposed to be or even than what SVG is used for today.

pcwalton2• 5 years ago

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.

dosshell• 5 years ago

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?

andybak2• 5 years ago

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• 5 years ago

I can't imagine those good words ever came from anyone that has actually used it.

heleninboodler• 5 years ago

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.

nigeltao• 5 years ago

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.

pcwalton2• 5 years ago

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• 5 years ago

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

tdeck2• 5 years ago

"somewhat bloated" is the understatement of the century. PDF documents can contain executable code in two different programming languages (JavaScript and PostScript), interactive content, digital signatures, their own form of encryption, and more. Why they thought adding JavaScript to an already infamous attack vector of a format is beyond my understanding.

maxerickson• 5 years ago

PDF/A is a standard with a bunch of features excluded.

adrianN• 5 years ago

PDF is indeed a very bloated format, but documents are inherently complex. I don't think you can create anything that deserves the name "tiny" but can still handle anything you might want to send to a printer (and that's a much smaller use case than "anything you want to display on a screen").

niutech2• 5 years ago

For PDF there are OpenXPS and DjVu.

justinclift• 5 years ago

Lottie has already displaced SVG for animation/motion graphics ...

Looking at the website, it seems like the file format is OSS but the creation side of things is proprietary?

hobofan• 5 years ago

Ongoing thread about Lottie, which also highlights some OSS options for creating Lottie files: https://news.ycombinator.com/item?id=29634114

HideousKojima• 5 years ago

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

BudaDude• 5 years ago

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 .

MisterBiggs• 5 years ago

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?

jlarocco2• 5 years ago

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.

hutzlibu3• 5 years ago

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)

__m• 5 years ago

That’s a bit revisionist history. Flash was pretty popular and animations haven’t gone away.

bsder• 5 years ago

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• 5 years ago

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.

sigg3• 5 years ago

<marquee>Bring Me Back!!</marquee>

pcmaffey• 5 years ago

For some tasteful svg animation examples, check out my blog articles.

[1] https://www.pcmaffey.com

ikskuh23• 5 years ago

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

dnautics4• 5 years ago

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.

jancsika4• 5 years ago

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.

styfle• 5 years ago

Looks really interesting!

Can TinyVG be converted to other image formats, such as PNG?

ikskuh23• 5 years ago

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

mmcgaha4• 5 years ago

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.

ikskuh23• 5 years ago

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

shatteredgate7• 5 years ago

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.

mro_name2• 5 years ago

S-expressions, finally! Thanks!

tromp3• 5 years ago

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

mmcgaha4• 5 years ago

Lovely example! Beautiful postscript makes me warm and fuzzy inside.

earleybird2• 5 years ago

Apologies for being off-topic and possibly absurd question - could the binary lc be considered a concatenative language?

kingcharles• 5 years ago

Thinking about SVG and EPS inside a PDF reminds me of a Turducken Ꙭ

anyfoo5• 5 years ago

without the need for expensive/complex/insecure libraries.

Maybe because in the formats named, the image format is the expensive/complex/insecure libraries? I know that sounds a bit snappy, but I felt the author of TinyVG made a pretty good case for what they're aiming at: a simple vector format that does not come with a (or even multiple, in at least the case of PDF) Turing complete kitchen sinks.

mmcgaha4• 5 years ago

You are 100% right. I will now throw out all of my work because despite being easy to generate, I could accidentally generate an image that does something bad (do you even halt bro?) and I don't want to do that. So I will throw out my simple well tested native solutions and replace them with a solution that needs to be compiled to a native solution.

matthewmacleod• 5 years ago

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.

ikskuh23• 5 years ago

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.

tracnar• 5 years ago

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

exabrial• 5 years ago

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

cryo• 5 years ago

This looks interesting. Small issue, the link to the SDK manual currently throws a 404:

https://tinyvg.tech/download/tinyvg-sdk-readme.txt

ikskuh23• 5 years ago

whoopsies. CI failure on my side, will be fixed in roughly 20 minutes

goodmachine2• 5 years ago

what's wrong with SVGTiny?

https://www.w3.org/TR/SVGTiny12/index.html

the_duke2• 5 years ago

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.

userbinator3• 5 years ago

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

mdswanson• 5 years ago

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.

userbinator3• 5 years ago

You can define sprites in SWF too.

hutzlibu3• 5 years ago

Yeah, SWF looked promising in its day and its a shame it is basically dead(?)

richardanaya2• 5 years ago

Mesh gradients might make and impressive feature!

ikskuh23• 5 years ago

Can you elaborate that and provide some sources on what a mesh gradient is?

jancsika4• 5 years ago

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?

ikskuh23• 5 years ago

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

nine_k2• 5 years ago

This is a problem with any image format. Either you embed the font (or parts of it), or convert the text to curves.

Shared4042• 5 years ago

There's images that don't render anywhere except inkscape

You just have to convert the text in the image to a path before using it wherever you plan on, just be sure to save the original for editing.

templix4• 5 years ago

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.

nomel• 5 years ago

I've seen impressive amounts of code written to get around one line bugs that could be trivially fixed, if only reported. One time, the LOC of the workaround basically matched the LOC of the tool, with the workaround implementing a full parser to consume the output of the tool, rather than just directly loading the json the tool was consuming. I used to get frustrated at these things, but I've become a bit demented, reveling in the asinine, self inflicted, suffering that I sometimes witness. Watching people copy paste code changes, rather than using git, is an infinite source of entertainment that's seemingly impossible to stop.

the_duke2• 5 years ago

Nope, I also encountered text rendering issues with SVG.

I reckon devs will just drop SVG in favor of a PNG or re-export with text as paths instead of complaining somewhere.

chrismorgan• 5 years ago

What’s the deal? The font-size declaration in the style attribute was invalid, and Chromium allowed it, in direct contravention of both the SVG 1.1 and 2 specs, while Firefox disallowed it.

SVG 1.1 extends CSS 2’s font-size value to allow a unitless number on a font-size SVG attribute <https://www.w3.org/TR/SVG11/text.html#FontSizeProperty>, but when you specify it as a CSS style it must follow the CSS declaration form, which means that non-zero lengths must include a unit—<https://www.w3.org/TR/SVG11/styling.html#StyleAttribute> even explicitly mentions font-size as its example on this point.

SVG 2 removes the unitless number extension and defers to CSS Fonts Module Level 3 entirely for font-size, so that unitless non-zero numbers aren’t permitted even in a font-size attribute.

All up, it’s a bad example that doesn’t support the thesis in the slightest, because a rookie error was made. (There’s still something in the fact that such an error could be made so easily, but it’s not that big a deal, certainly not enough to suggest that text is unreliable beyond the fact that you don’t know what fonts are available.)

Text in SVG is just as good as text in HTML, except inasmuch as nothing implements runtime (font-dependent) line wrapping, so it’s kinda more like HTML with white-space:nowrap.

The interactions between presentation attributes and style properties are a bit fiddly and sometimes unclear. Take something like <rect x="2" y="2" width="calc(100% - 4px)" height="calc(100% - 4px)"/>; it’s not quite clear to me whether this is valid in SVG 1.1, though I think it should be in SVG 2. It works in both Firefox and Chromium, though Firefox logs a claim that it’s invalid in the dev tools. <rect style="x:2px;y:2px;width:calc(100% - 4px);height:calc(100% - 4px)"/>, on the other hand, is definitely fine.

jancsika4• 5 years ago

Text in SVG is just as good as text in HTML, except inasmuch as nothing implements runtime (font-dependent) line wrapping, so it’s kinda more like HTML with white-space:nowrap.

That's quite a caveat. How many current webpage designs depend on wrapping happening in exactly the same way across all browsers and device dimensions?

pier25• 5 years ago

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

ikskuh23• 5 years ago

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

28uwedj• 5 years ago

Tiny differences? Shits blurry as hell.

flohofwoe• 5 years ago

Looks crisp here on a 14"MBP (this demo: https://tinyvg.tech/polyfill/index.htm)

akdor1154• 5 years ago

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.

ikskuh23• 5 years ago

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.

CliffStoll• 5 years ago

Yes!

For a pen plotter, I'd like something like SVG that has color, pen-pressure, and pen-rotation.

CamperBob2• 5 years ago

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.

ikskuh23• 5 years ago

So i did the dance with a single file (my starter file):

It's the "shield-account" from material design.

    353 shield.svg
    246 shield.svg.gz
    119 shield.tvg
    139 shield.tvg.gz

Looks like tvg is so well compressed that using gzip compression doesn't help and beats compressed and optimized svg still by a magnitude of two. We'll get better numbers when i find time to improve the benchmark.

TinyVG was also designed to be used on constrained embedded systems with low RAM, and i have a proof of concept that it can render medium complexity files with less than 32k RAM without memory optimizations in the reference implementation. NanoVG doesn't seem to support streaming render events either, so it isn't suitable for low memory profiles as it creates a DOM that will be rendered

sysrpl• 5 years ago

I am not sure how relevant this is, but I recently published a proof a concept library that converts SVG documents into simulated machines. See the link below.

https://www.getlazarus.org/videos/physics/blueprint/

The rendering in my library relies upon OpenGL and the NanoVG library. My library is called Tiny Sim. All of these nano tiny and vg names seem to be colliding adding a bit of confusion in my opinion.

culi• 5 years ago

This is actually just like... aesthetically pleasing to watch. As someone who loves watching/reading about Game of Life lifeforms, I'd love to see some sort of gallery where people can share their creations and/or build upon other people's

post-it• 5 years ago

Very reminiscent of Line Rider.

https://www.linerider.com/

kinduff• 5 years ago

This brings me back, loved this game and I'm impressed with the updated version.

richardanaya2• 5 years ago

I love this Zig art.

cheeaun• 5 years ago

Wondering how is this compared to Ian Hickson's research: "A vector format for Flutter (and beyond)" https://docs.google.com/document/d/1YWffrlc6ZqRwfIiR1qwp1AOk...

Eduard• 5 years ago

What about accessibility? SVG can support it, https://www.w3.org/TR/SVG/access.html

Just converting text to vector paths will ruin accessibility, and also hurt SEO / discoverability.

nine_k2• 5 years ago

If you need complex graphics that need multiple accessibility nodes, stick with SVG.

If you need the "tiny" part of TinyVG, add an aria label to the UI node that renders it. Should work well for icons, logos, etc.

vjeux• 5 years ago

I was hoping to make an excalidraw exporter to TinyVG but unfortunately it doesn't support text. It makes sense given that rendering text is horrible but doesn't work with this use case.

ikskuh23• 5 years ago

If excalidraw supports conversion of text to paths, you can do it!

41b696ef11132• 5 years ago

@ikskuh -I do not see any mention of layers or grouping in the specification (unless it went by some other terminology I missed in my skim). In the blog post you said you wanted to avoid having an "authoring" file and a "redistributable" version. I am far from an artist but have hacked out a few .svg sketches and layers/grouping are a requirement for creating new content.

ikskuh23• 5 years ago

I think you got me wrong then. I WANT authoring files and redistributables to differ. Nobody should send SVG, xcf, psd files to the consumers. We use PNG or JPEG for pixel graphics, why not send of TinyVG instead of SVG, but use SVG as the source file.

This is what i've done for a lot of test files until i had the TinyVG text form ready.

Also, we should not edit graphic files in a code editor. We have better tools for that

41b696ef11132• 5 years ago

Whoops. Well then sounds great.

est2• 5 years ago

The best streamable vector animation format was invented 20 years ago, called Macromedia Shockwave Flash. It was killed by poor mobile processors and Steve Jobs' "Thoughts on Flash"

userbinator3• 5 years ago

poor mobile processors

I don't think even the first generation of iPhone (400MHz ARM) was too slow to run the average Flash games of the time, given that SWF was originally designed to work well on mid-90s PCs (200-300MHz Pentium/Pentium II).

and Steve Jobs' "Thoughts on Flash"

That's more likely.

est2• 5 years ago

was too slow to run the average Flash games of the time

The peak performance was enough, but the it will drain battary very quickly.

cmrdporcupine• 5 years ago

It was killed by its vendor's poor implementation (poor performance, battery eater on mobile and on laptops) and lack of effort to port to and support non-Wintel platforms.

CyberRabbi4• 5 years ago

Why not just implement a subset of SVG?

ur-whale3• 5 years ago

Why not just implement a subset of SVG?

XML

CyberRabbi4• 5 years ago

Just curious how does XML prevent you from implementing a subset?

ur-whale3• 5 years ago

What we definitly don't need is a vector graphic format that can do raw sockets.

Amazing.

mfabbri77• 5 years ago

Tiger rendering issue: https://imgur.com/a/huaKQgk

Your effort to create a lightweight vector file format with these features is really appreciable, even if it can never replace SVG for the more general use case. Anyway the tiger has rendering problems (I am quite obsessed with this tiger: even my rasterizer initially did not draw it correctly).

Spoiler: I'm one of the developers of AmanithSVG - http://www.amanithsvg.com

ikskuh23• 5 years ago

Oh, good catch. But this is actually not a problem in the rendering, but a conversion problem from SVG to TinyVG. The converter doesn't do hierarchical attributes yet, so if something uses a <g> to disable filling, it will still fill those elements

badsectoracula• 5 years ago

This looks nice, i was thinking of adding some vector support in my Little Forms[0] GUI toolkit at some point but everything feels overcomplicated and bloated - however this looks quite nice at a first glance. As i don't have any advanced vector drawing code at all (aside from the basic "draw line, draw circle" etc needed to draw the GUI itself) it can work as a template for what to put in there.

[0] http://runtimeterror.com/tech/lforms/

cycomanic• 5 years ago

I really appreciate the idea, but with the given subset I really like to know more about the use case. The only one I can think about is icons. Considering that there is no animation support, only two point gradients and no text support (as far as I understand the spec), that rules tinyvg out for pretty much 95% of what I use vector graphics for.

If I want to have use those features I now need two (or more) formats, which kind of defeats the point of a less complicated format, for size, complexity and security reasons.

m_eiman• 5 years ago

It would be interesting to see how it compares to Haiku Vector Icon Format, which shares some of the same priorities. Some more info:

https://en.wikipedia.org/wiki/Haiku_Vector_Icon_Format

http://blog.leahhanson.us/post/recursecenter2016/haiku_icons...

degurechaff• 5 years ago

It seem TinyVG don't support LOD which I think an important feature for icon use case

RazrFalcon2• 5 years ago

A small nitpick as the resvg author: the repo located here https://github.com/RazrFalcon/resvg I'm not sure why the author linked some random, outdated fork. If you're trying to beat SVG, you should have done a better research.

But yes, SVG is extremely bloated and under-documented. Especially SVG 2. The core resvg codebase is close to 20 KLOC, while the whole package is like 50 KLOC.

On the other hand, resvg is an exception, because it doesn't rely on any system and/or 3rd party libraries. 95% of the code in the final binary was written by one person (me). Not because it was strictly required, but because it was fun. resvg is basically an epitome of RIIR.

Loic• 5 years ago

RIIR : Rewrite It In Rust.

Just because I had to lookup this, for me, new acronym.

ikskuh23• 5 years ago

Oh, hi!

A small nitpick as the resvg author: the repo located here https://github.com/RazrFalcon/resvg

Oh, i didn't see this. Thanks for some more correct and real numbers, i will correct them in the article later!

I'm not sure why the author linked some random, outdated fork.

because it appears way higher up on the google search if you search for "svg rendering library". Sorry i didn't recognize that it's a fork!

Nice work then! I should check it out for SVG rendering and parsing.

How much work would it be to port over the C# SVG→TinyVG converter to Rust based on resvg? Considering that you already have a well done parser compared to mine...

RazrFalcon2• 5 years ago

How much work would it be to port over the C# SVG→TinyVG converter to Rust based on resvg?

Probably a day, as long as you know Rust. I can take a look into it if you're interested. usvg (the SVG parser of resvg) is specifically designed to convert a real world SVG with all its quirks into a machine readable, minimal SVG/XML.

One thing to note is that usvg doesn't preserve text at the moment (will be converted into paths automatically) and Quadratic curves.

PS: I also have a longer, but still unfinished rant [0] over SVG complexity if you're interested.

[0] https://github.com/RazrFalcon/resvg/blob/master/docs/renderi...

niutech2• 5 years ago

Apart from SVG, there are long-standing and well-established formats for vector graphics: Enhanced Metafile (EMF) and Encapsulated PostScript (EPS). Why not use them instead of a new file format?

Const-me2• 5 years ago

This is awesome! A few notes on the formats.

magic must be { 0x72, 0x56 }

I usually use weird non-ASCII bytes in file signatures of binary formats. Many tools will then correctly identify the file as binary data.

RGB 565

Not important, but I would remove that. In hardware, these 16-bit formats is a thing of the past. Nowdays, you only saving 2 bytes/color compared to RGBA8, for non-trivial complexity cost.

with the color channels encoded in sRGB

I would add another field in the file header for color space. For RGBA8, sRGB is the only reasonable choice, for FP32 colors however, linear colorspace is very reasonable for some applications.

VarUInt.. encoded as a variable-sized integer that uses 7 bit per byte for integer bits and the 7th bit to encode that there is ”more bits available”.

This means you need to parse the complete uint just to skip the field, less than ideal. MKV does it much better https://www.rfc-editor.org/rfc/rfc8794.html#name-variable-si... you only need the first byte to find out the length. Note all modern CPUs have bswap instruction or an equivalent to load integers from memory while flipping endianness to little endian.

Arc Ellipse

Even circular arc segments are relatively hard to implement. The only reason it’s relatively hard and not insanely hard, formulae created for SVG and similar: https://www.w3.org/TR/SVG/implnote.html#ArcConversionEndpoin... Pretty sure elliptical arc segments going to be insanely hard to implement and debug. Another thing, AFAIK no authoring software supports these splines, how people are supposed to get vector art with these things?

kabdib• 5 years ago

Typo early in the format documentation, where the text has an example:

     (byte & 0x1F) >> 3

should probably be

     ((byte >> 3) & 0x1f)

... or something like that.

Const-me2• 5 years ago

Also, important stroke parameters are missing, line joins and caps. See pictures on these pages for illustrations: https://docs.microsoft.com/en-us/windows/win32/api/d2d1/ne-d... https://docs.microsoft.com/en-us/windows/win32/api/d2d1/ne-d...

jokoon• 5 years ago

Wouldn't it be possible to use SVG for things that are done with HTML+CSS?

Seems like doing a webpage with SVG instead of CSS would also allow more flexible web design.

dragonwriter2• 5 years ago

Seems like doing a webpage with SVG instead of CSS would also allow more flexible web design.

Seems exactly the opposite to me.

But maybe I don't understand the intended sense of “flexible” intended.

randomcarbloke• 5 years ago

if I give this to my laser cutting guy is he going to be annoyed?

auxym• 5 years ago

From my experience, laser cutting shops (we're talking about steel plate cutting right?) are annoyed with everything except DXF.

jmiskovic2• 5 years ago

It's common to think of vector art of 'ground truth' and bitmaps as sampled image, but SVG and TinyVG don't add so much over bitmaps. When you zoom into 100-point polygon, you still reach the limit where there is no additional details. Those 100 points are in fact samples, an approximation of artist's intention. When boolean operations are preformed on polygons, information gets lost and the shapes degenerate. The SDFs in 3D modeling seem more pure way of defining and manipulating shapes than polygons and bezier curves.

TinyVG doesn't implement node referencing. In SVG it is done by the `clone` operation, which creates SVG node that references original shape. Using this you can build smart scenes with shadows, reflections, arrayed clones and other interesting effects. It's like DRY principle for art; you can later modify the original shape and see changes reflected in other parts of the scene.

TinyVG doesn't even seem to have object groups. If I wanted to draw a gauge and control needle rotation in runtime I would have to manually re-compute path coordinates each frame. In SVG I would group all parts the gauge needle, and in each frame I would update just the rotation angle in group transform.

For a vector format to de-throne the SVG I would expect it to be smarter than SVG while discarding legacy features. I'd like to see things like infinitely large dimensions for shapes (shapes for ground and sky, or a ray of sun), specifying design constraints, interactivity and procedural animations. IMO the TinyVG takes vector graphics into wrong direction, as a boring subset of SVG.

Edit: I like that TinyVG takes form of very readable lisp-like data description language. Maybe it could be used as a starting point for a smarter vector format for authoring graphics and not just for distributing the end results.

unionpivo2• 5 years ago

You are talking about 2 vastly separate things.

Most uses today of SVG, that I have seen in the wild are icons, graphs and diagrams. Which this TinyVG covers beautifully. Especially for embeded (TinyVG's authors motivation for this) you often need some icons.

Sure if you need something more complex keep using SVG, or create something new. But for 80% - 90% off web and embedded its enough.

TinyVG doesn't implement node referencing. In SVG it is done by the `clone` operation, which creates SVG node that references original shape. Using this you can build smart scenes with shadows, reflections, arrayed clones and other interesting effects. It's like DRY principle for art; you can later modify the original shape and see changes reflected in other parts of the scene.

TinyVG is final format optimized for rendering. You can design your graphic with all those futures, and then render them to TinyVG.

DRY doesn't apply since you will not be writing it by hand anyway, but use a tool.

Author clearly states that this is not an Authoring format, but display format. What you are looking for is better authoring format.

Edit: I like that TinyVG takes form of very readable lisp-like data description language. Maybe it could be used as a starting point for a smarter vector format for authoring graphics and not just for distributing the end results.

That's not TinyVG format. That is just sample generator that comes with TinyVG suite. TinyVG is binary format, and you can't edit it with text editor

jmiskovic2• 5 years ago

For web and embedded I would still need to dynamically control transforms of object groups. Otherwise the graphics is baked and I can just as well use PNG.

Just like bitmaps, vector graphics looks best when it is displayed at size it was designed for. Too small and details will just blur together; too large and the design looks overly simple with unnaturally sharp edges.

chrisweekly• 5 years ago

Related tangent: despite its age this "SVG Can Do That?" preso by the inimitable Sarah Drasner still floors me every time:

https://slides.com/sdrasner/svg-can-do-that

stuaxo• 5 years ago

Possibly because I am interested in animation, I immediately want some of the things removed, like hierarchy.

With a hierarchical system you can do things like bones for animation.

RyanGoosling2• 5 years ago

SVG is great. CSS is great. Both are not difficult to understand, relatively. There are existing libraries. Why reinvent the wheel? Does this reinvent CSS too?

tromp3• 5 years ago

For Haskell fans, there is diagrams [1]:

"a powerful, flexible, declarative domain-specific language for creating vector graphics, using the Haskell programming language."

[1] https://diagrams.github.io/

TinyVG: A challenger to the throne of vector graphics

Related Stories