Live data from Hacker News

Wuffs’ PNG image decoder

nigeltao.github.io

61–70 of 144 posts

Re: Wuffs’ PNG image decoder

#61
post #2

Interesting. 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 u…

Wuffs touts its lack of memory allocation as a safety feature [0]. Rust could add a `#![forbid(alloc)]` declaration and achieve the same effect. I think this would be a good idea.

Wuffs types are not parameterized with lifetimes, so they may contain references only to items with static lifetime. This means that Wuffs cannot implement linked lists, hash tables, or other common data structures. To support those structures, Wuffs will need to either add lifetime parameters and a borrow-checker (like Rust) or add reference counting (like Rust `Arc`, C++ `shared_ptr`, Golang, Java, etc).

[0] https://github.com/google/wuffs/blob/v0.3.0-beta.1/doc/note/...

Re: Wuffs’ PNG image decoder

#62
post #58

why did the title change on this submission? is it not the fastest in the world?

The title changed multiple times. I've seen at least 3 in the last 30 minutes (safest, fastest and now this one).

why? usually I only see this happen for misleading headlines and appending "(year)" to old articles that might be construed as recent. what's misleading about the actual article's headline? as far as I can tell it seems to be true.

Re: Wuffs’ PNG image decoder

#63

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

Rust does as much as possible at compile time, and some of its most famous features are entirely at compile time, but it will also use runtime checks where appropriate. Some amount of runtime checking is inherent in any program. Even dependently typed programs must, for example, check input at runtime. They can make it easier to have absolutely minimal runtime checks, however. Rust is adding a limited form of depende…

I've not been following recent Rust development as closely, can you elaborate on what limited form of dependent types Rust is adding?

Re: Wuffs’ PNG image decoder

#64
post #2

Interesting. 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 u…

Wuffs touts its lack of memory allocation as a safety feature [0]. Rust could add a `#![forbid(alloc)]` declaration and achieve the same effect. I think this would be a good idea. Wuffs types are not parameterized with lifetimes, so they may contain references only to items with static lifetime. This means that Wuffs cannot implement linked lists, hash tables, or other common data structures. To support those structu…

Isn't that stupidly limiting?

Re: Wuffs’ PNG image decoder

#65

Earlier quoted context omitted.

Rust does as much as possible at compile time, and some of its most famous features are entirely at compile time, but it will also use runtime checks where appropriate. Some amount of runtime checking is inherent in any program. Even dependently typed programs must, for example, check input at runtime. They can make it easier to have absolutely minimal runtime checks, however. Rust is adding a limited form of depende…

I've not been following recent Rust development as closely, can you elaborate on what limited form of dependent types Rust is adding?

Functions and types can take integers as monomorphization-time template parameters (const generics).

It would be nice if you could pass (n, t) where n is supplied at runtime, the type of t depends on the value of n, and the compiler only lets you use t if your code is valid for all reachable values of n.

eg. fn(n: usize, arr1: &[i32; n], arr2: &[i32, n]) allowed the function body to assume the two slices can be zipped without losing elements.

Note that i don't have enough experience with either dependent types, zz, or wuffs to explain much further.

Re: Wuffs’ PNG image decoder

#66
post #7

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

Halide (https://halide-lang.org/) is one example, designed for implementing low-level image processing functions.

Re: Wuffs’ PNG image decoder

#67
post #7

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

Futhark is a auxillary language that targets parallel processors (e.g. GPUs) to be used alongside a general purpose language.

Re: Wuffs’ PNG image decoder

#69
> decompressing the entire image all-at-once (into one large intermediate buffer) instead of one row at a time (into smaller, re-usable buffers). All-at-once requires more intermediate memory but allows substantially more of the image to be decoded in the zlib-decompressor’s fastest code paths.

Mozilla's imagelib has a neat trick to gain performance while working with smaller memory buffers when you want to render the output image at a smaller resolution than it is encoded. They call it downscale-during-decode.

So this library pulls zlib decompression into the decode loop. Imagelib on the other hand optimizes at the other end of the pipeline and pulls downscaling into the decode loop.

imagelib's optimization has the advantage that it helps with both small images as long as they're not displayed pixel-exact and also makes decoding humungous images feasible without causing the browser to explode with OOMs.

Post reply on HN