ikskuh

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

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

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

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

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

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.

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

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

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!

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

It has something different. Kristall parses HTML with gumbo and will re-emit cleaned HTML code that is then displayed as a rich text document.

It doesn't have inline images or anything, but only the text content

Yes, most of my systems have "zig cc" as a C compiler installed nowadays. Why? It's so much easier to install. Especially on systems like windows, and i get other benefits. One example: "I can send you a project, and you can just compile it." Dependencies? "Zig toolchain, any OS"

I haven't had this experience with any other language. When a package manager lands, you won't even have to install any SDKs by hand anymore.

Most of them are actually the same and on several microcontrollers you can even just access them as an array of structs, selecting each port at runtime. HALs try to hide these facts which you can only find out about in the hardware documentation

Most GPIO defs are just "this is a struct at 0xAABBCCDD"

> When this is brought up, people [...] don't seem to acknowledge that this is not a problem with any other language.

This was a deliberate design decision by andrew for all zig pre-1.0 to supress discussions about coding style (use CR, LF, CRLF, LFCR as a line ending? tabs vs. spaces? ...) as it's considered bike shedding

Zig 1.0 won't have this restrictions anymore. More information can be found here:

https://github.com/ziglang/zig/wiki/FAQ#why-does-zig-force-m... https://github.com/ziglang/zig/issues/544

Note that tagged releases in zig are just "the first state that worked with the new LLVM version".

Imho it would be unreasonable to even try keeping backwards compatibility in a language that tries to find the global maximum

> but geez this is a Hello, World sample that fails This is because the 0.7.0 release cycle changed a lot about logging: std.debug.warn was used as a general purpose log function in 0.6, but is now deprecated to move people to use the std.log namespace now

> It'd be nice if your getting started guide only used features from the tagged latest version at least...

The problem here is that package manager maintainers only package tagged versions which isn't really a good thing for zig. Your version is kinda outdated as soon as you downloaded it. Most projects won't break anymore on a daily basis, but there is still changes, bug fixes and additions.

I'm currently waiting for some PRs to be merged, so i can continue my own projects. You won't get this when sticking to tagged releases (and it will make updating your projects way more painful than keeping them up-to-date on a daily basis)

But yeah, ziglearn could note that using a tagged version has these problems and that zig is moving so fast that sticking to a tagged version will yield outdated code very quickly

Zig is also designed around safety and security. It's not as obvious as with Rust, but it's still there.

Zig is way easier to verify than rust code (no hidden control flow, no hidden allocations that might fail, ...) which means a security expert can read a single function (without knowing more about the code) and can reason about that function.

This does not work in languages like C++ and Rust where RAII is a common pattern and code will be implicitly be executed when some objects go out of scope.

Yes, sure. Rust does a lot of verification work already, but so do tools like cppcheck and other verification tools and i'm sure those will emerge for Zig as well.

Zig (in contrast to C or Rust) has no warnings. Behaviours that might not be OK are compile errors and cannot be ignored. There are also plans (as in "not implemented yet") to forbid declaring unused variables and such so even this gets a compile error. This makes Zig also easy to reason about (seeing a variable declaration means that it's guaranteed to be used later)

One experience i can share with Zig and webdev is this:

I was writing a emulator (and later: a compiler) in Zig which was originally written for PC. But i got the idea that hosting this stuff on the web page would be cool, so i learned how to do Wasm. The result was for both project a glue file with ~150 LOC Zig and ~150 JS and both compiler and emulator ran in the browser, and porting both projects took less than an afternoon of time.

The overall idea is to have a selfhosted compiler for debug and release builds where the release build as ~80% of LLVM performance and use LLVM as an optional dependency to go 100% performance

Yes, you understood that right. The existing executable file is not written completly anew.

And yes, it will be faster. The way Zig does this is by only recompiling and modifying the parts of the executable where the source has changed. Imagine a project like chromium, where your executable is 150 MB large. Now you change a single function. Classic linking would require the whole linking process and the write of 150 MB of code. Zig will only compile and patch a single function (when lucky: less than 1kB) and emit this. Less I/O, less overall work to do.

> I see very few people suffering from such burdens, but a great many suffering from its exact opposite: using a low- or mid-level language to write hundreds of lines where ten lines in a higher-level language would suffice and be more easily verified as correct.

I see a huge load of people suffering from those burdens. Higher-level languages tend to be less efficient and less optimal. Yes, they take a burden from the programmer and move that burden onto the end user.

So the programmer is having the easy life, while every user now waits a second longer for the program startup, a second longer for opening the file dialog, and so on. Doesn't sound much, but if you think about it: Worst case is: 1 programmer shaved off two weeks of work on an app that is used by every person on the planet. 7 billion users lost 1 second. In total, humanity lost roughly 200 years of productive time when every person starts the app exactly once.

Modern computers are incredibly fast and we as programmers use that brutal power to be more lazy than before instead of leveraging that power to all of the users of our tools. We could have systems that go from clicking the power button to being readily available for use in less than seconds. Think about this when you chose a high level language that exchanges programmer convenience for runtime cost and think about if it other peoples time is worth your lazyness.

</rant>

disclaimer: don't take it personally, i'm just frustrated about imperformant software