libdeflate VS bitter

zune-inflate is a port of libdeflate to safe Rust.

> The QOI benchmarks shows it only lagging a small bit behind PNG in compression ratio, while performing much faster (multiples) in both encoding and decoding.

Presumably that’s with stock libpng, which uses zlib. I wonder if anyone tried patching it to use the substantially faster (on x86) libdeflate[1] instead? It doesn’t do streaming, but you shouldn’t really need it for PNG textures.

[1] https://github.com/ebiggers/libdeflate

Eric biggers libdeflate https://github.com/ebiggers/libdeflate/blob/master/lib/deflate_decompress.c

Note that libdeflate has used essentially the same method since 2016 (https://github.com/ebiggers/libdeflate/blob/v0.4/lib/adler32...), though I recently switched it to use a slightly different method (https://github.com/ebiggers/libdeflate/blob/v1.12/lib/x86/ad...) that performs more consistently across different families of x86 CPUs.

Going away from Zlib proper but staying with its format, there’s libdeflate[1], an implementation that’s substantially faster on modern machines but can’t stream, and of course Zopfli[2], a glacially slow compressor that’s somewhat better (and occasionally much more so).

[1] https://github.com/ebiggers/libdeflate

[2] https://github.com/google/zopfli

bitter v0.6 is a pretty major change in the library as the API surface area is much slimmer and additional performance gains have been unlocked by allowing control of when the lookahead buffer is refilled to be passed downstream, so that one can take advantage of patterns in the data they are decoding.

What I've done for my crates (example #1) is take the csv that criterion generates and formulate better graphs using technologies designed for visualizations (like the R ecosystem).

Updated the benchmark with your implementation! You can see the results here: https://github.com/nickbabcock/bitter#comparison-to-other-li...