ZLib VS libdeflate

A fix has been checked into the upstream git repo: https://github.com/madler/zlib/pull/843 but a release has not yet been made including it.

So the real issue here is that the lack of tree validation before the tree construction, I believe. I'm surprised that this check was not yet implemented (I actually checked libwebp to make sure that I was missing one). Given this blind spot, an automated test based on the domain knowledge is likely useless to catch this bug.

[1] https://github.com/madler/zlib/blob/master/examples/enough.c

In the source code of the Node.js opensource project, lib folder contains JavaScript code, mostly wrappers over C++ and function definitions. On the contrary, src folder contains C++ implementations of the functions, which pulls dependencies from the V8 project, the libuv project, the zlib project, the llhttp project, and many more - which are all placed at the deps folder.

Seeing the text in red got me thinking for a moment, "wow, didn't realize pirates had such love for an open-source compression library"

cd "${srcdir}/zlib-$pkgver/contrib/minizip" make install DESTDIR="${pkgdir}" install -D -m644 "${srcdir}/zlib-$pkgver/LICENSE" "${pkgdir}/usr/share/licenses/minizip/LICENSE" # https://github.com/madler/zlib/pull/229 rm "${pkgdir}/usr/include/minizip/crypt.h"

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