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

131–140 of 196 posts

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

#131

Post by ikskuh »

41b696ef1113 wrote: post #107

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

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

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

#132

Post by ikskuh »

vjeux wrote: post #101

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.

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

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

#133

Post by ikskuh »

dragonwriter wrote: post #115
ikskuh wrote: post #58

Earlier quoted context omitted.

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…

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

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

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

#134

Post by mro_name »

ikskuh wrote: post #26
mmcgaha wrote: post #18

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.

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

S-expressions, finally! Thanks!

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

#135

Post by mro_name »

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.

XML and YAML (including it's JSON representation) are complexity nightmares. But especially for xml, the tooling makes them appealing to use as e.g. distribution format with JS-less browser templating.

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

#137

Post by RazrFalcon »

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.

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

#138

Post by Loic »

RazrFalcon wrote: post #137

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

RIIR : Rewrite It In Rust.

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

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

#139

Post by Const-me »

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?

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

#140

Post by kabdib »

Const-me wrote: post #139

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…

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.
Post reply on HN