3 ms·

I recently wrote a Rust PNG decoder mostly for use in no_std contexts, and it was motivated out of wanting to decode emoji for a font rasterizer. I didn't real

I recently wrote a Rust PNG decoder mostly for use in no_std contexts, and it was motivated out of wanting to decode emoji for a font rasterizer. I didn't really put any effort into optimizing it yet, though it does use miniz_oxide and it decompresses the entire image at once instead of per-scanline. I'm curious if it is at all competitive with the Wuffs decoder, I'm guessing probably not because I haven't put any effort into using SIMD. https://github.com/bschwind/png-decoder https://github.com/bschwind/png-decoder But overall the implementation was pretty straightforward, I just read the RFC and wrote it out over a few weeks. One quirk of my library currently is it always returns an RGBA buffer, instead of potentially letting you save memory on a grayscale or RGB image.

nigeltao 6y ago
> I'm curious if it is at all competitive with the Wuffs decoder You could try adapting https://github.com/google/wuffs/tree/main/script/bench-rust-png https://github.com/google/wuffs/tree/main/script/bench-rust-... > https://github.com/bschwind/png-decoder https://github.com/bschwind/png-decoder Note that statements like: let bytes_per_scanline = ((header.width * header.bit_depth as u32 * header.color_type.sample_multiplier()) + 7) / 8; can silently overflow a u32 if width is 0x800_0000, bit_depth is 8 and sample_multiplier is 4. Part of the point of Wuffs is to catch things like that (at compile time).
- bschwindHN 6y ago
  > You could try adapting ... Do you accept PRs for the Rust benchmarks? My code is nowhere near competitive to the Wuffs implementation, but it would be a fun goal to work towards. > Note that statements like ... can silently overflow a u32 Thank you for catching that, I'll go through the entire codebase and try to fix those up. That's a part of Rust that always makes me feel uneasy - the compiler will tell you if you're doing math with numbers of different bit widths, but it won't warn you in most cases about overflow. That would be a good addition to the Rust compiler, or at least a Clippy lint.
  - nigeltao 6y ago
    > Do you accept PRs for the Rust benchmarks? Sure! I'll take a PR that adds script/bench-rust-png-decoder to the Wuffs repo. I'll also take patches to script/bench-rust-png. I'm not as fluent in Rust as I am in C/C++ or Go, so I might easily be doing something silly there.

nigeltao 6y ago

> I'm curious if it is at all competitive with the Wuffs decoder You could try adapting https://github.com/google/wuffs/tree/main/script/bench-rust-png https://github.com/google/wuffs/tree/main/script/bench-rust-... > https://github.com/bschwind/png-decoder https://github.com/bschwind/png-decoder Note that statements like: let bytes_per_scanline = ((header.width * header.bit_depth as u32 * header.color_type.sample_multiplier()) + 7) / 8; can silently overflow a u32 if width is 0x800_0000, bit_depth is 8 and sample_multiplier is 4. Part of the point of Wuffs is to catch things like that (at compile time).

bschwindHN 6y ago
> You could try adapting ... Do you accept PRs for the Rust benchmarks? My code is nowhere near competitive to the Wuffs implementation, but it would be a fun goal to work towards. > Note that statements like ... can silently overflow a u32 Thank you for catching that, I'll go through the entire codebase and try to fix those up. That's a part of Rust that always makes me feel uneasy - the compiler will tell you if you're doing math with numbers of different bit widths, but it won't warn you in most cases about overflow. That would be a good addition to the Rust compiler, or at least a Clippy lint.
- nigeltao 6y ago
  > Do you accept PRs for the Rust benchmarks? Sure! I'll take a PR that adds script/bench-rust-png-decoder to the Wuffs repo. I'll also take patches to script/bench-rust-png. I'm not as fluent in Rust as I am in C/C++ or Go, so I might easily be doing something silly there.