Wuffs’ PNG image decoder
nigeltao.github.io
Wuffs’ PNG image decoder
1–10 of 144 posts
Re: Wuffs’ PNG image decoder
#2Interesting. First time I've head of Wuffs. As someone that still uses C, this in particular sounds neat:
(from https://github.com/google/wuffs#goals-and-non-goals)
""" Wuffs' goal is to produce software libraries that are as safe as Go or Rust, roughly speaking, but as fast as C, and that can be used anywhere C libraries are used.
[...] Wuffs the Library is available as transpiled C code. Other C/C++ projects can use that library without requiring the Wuffs the Language toolchain. Those projects can use Wuffs the Library like using any other third party C library. """
Re: Wuffs’ PNG image decoder
#3I wonder if the same performance benefits apply to Encoding PNGs.
Re: Wuffs’ PNG image decoder
#4I wonder if the same performance benefits apply to Encoding PNGs.
Looks like there isn't an encoder for PNG: https://github.com/google/wuffs/tree/main/std/png
Given the project goals, I guess most encoders don't make a lot of sense: For image encoding you basically provide an "x * y * bytes_per_pixel" memory area and an encoder does its magic on that. There isn't really any complicated untrusted input in that case.
Re: Wuffs’ PNG image decoder
#5I wonder if the same performance benefits apply to Encoding PNGs.
semi-related since the post is talking about Rust, oxipng is a decently fast PNG optimizer, albeit not an encoder per se: https://github.com/shssoichiro/oxipng
Re: Wuffs’ PNG image decoder
#6I wonder if the same performance benefits apply to Encoding PNGs.
Looks like there isn't an encoder for PNG: https://github.com/google/wuffs/tree/main/std/png Given the project goals, I guess most encoders don't make a lot of sense: For image encoding you basically provide an "x * y * bytes_per_pixel" memory area and an encoder does its magic on that. There isn't really any complicated untrusted input in that case.
Darn, I had a handful of NumPy arrays which could use a fast encoder.
Re: Wuffs’ PNG image decoder
#7My favorite part of the Wuffs github page has to be the definition it gives for Dependent Types
> ...Dependent types are a way to implement compile-time bounds checking, but they're not the only way, and there's more to programming languages than their type systems. Wuffs does not use dependent types.
Wuffs looks really interesting! I don't think I've ever even heard of a language that is designed to only be used in an auxiliary role along side another general purpose programming language!
Edit: As pointed out below, scripting languages like Lua are used in an auxiliary role, but in a very different way! Wuffs is designed for use in the deepest most crucial parts of an app, where as scripting languages are typically GC'd and used at the very highest levels, often times by animations, game designers, or even end users!
Re: Wuffs’ PNG image decoder
#8I wonder if the same performance benefits apply to Encoding PNGs.
Looks like there isn't an encoder for PNG: https://github.com/google/wuffs/tree/main/std/png Given the project goals, I guess most encoders don't make a lot of sense: For image encoding you basically provide an "x * y * bytes_per_pixel" memory area and an encoder does its magic on that. There isn't really any complicated untrusted input in that case.
The performance tradeoff isn't as justifiable, either: most images are decompressed orders of magnitude more times than they're compressed (generally just once).
Re: Wuffs’ PNG image decoder
#9> Also, unlike Go or Rust, Wuffs’ memory safety is enforced at compile time, not by inserting runtime checks that e.g. the i in a[i] is within bounds or that (x + y) doesn’t overflow a u32.
Am I missing something, or is this statement simply wrong? Have not used Go, but Rust checks its stuff at compile time as far as I know.
Re: Wuffs’ PNG image decoder
#10> Also, unlike Go or Rust, Wuffs’ memory safety is enforced at compile time, not by inserting runtime checks that e.g. the i in a[i] is within bounds or that (x + y) doesn’t overflow a u32. Am I missing something, or is this statement simply wrong? Have not used Go, but Rust checks its stuff at compile time as far as I know.
This was my understanding as well, at least for the majority of memory related tasks.
Edit: actually, it would help if I read the actual quote in your post. I think they’re right in saying that those things are checked at runtime in Rust, though I could be mistaken.