Joining the discussion, since I worked on the original optimization patches and I'm
one of the maintainers of Chromium's zlib.
Just seconding what Jeremy mentioned, it is possible to generate a valid DEFLATE stream
wrapped with GZIP format that may be different depending on the encoder used (e.g. zlib vs
libdeflate vs zopfli).
Specifically on the aarch64 specific patches, most probably the patch
0002-Porting-optimized-longest_match.patch would be responsible for the difference
observed when compared to a vanilla canonical zlib (i.e. Mark Adler's zlib
That optimization uses a slightly different strategy for finding the matching strings
while performing LZ77 compression.
Just to be on the safe side, I decided to write a small test case comparing the pixels of
the failing libreoffice test to verify if indeed, the decompressed data was a perfect
The test case can be found here (https://codepen.io/Savago/pen/BaKddem
). It displays
side-by-side the expected image and the generated image and by clicking in the button, it
will print the number of mismatched pixels and also a version of the image with the
mismatched highlighted pixels.
To prove that the test case is sound, there is another version here
) where I explicitly added some changes in the
generated image (i.e. added one eye, smile and a '4' symbol in the chest of the
icon using GIMP).
I also observed that the generated PNG is actually a few bytes smaller (2066 bytes vs 2102
bytes), which shows slightly better compression.
I hope that this should be enough to prove that there are no bugs in the optimization
patches used by Fedora.
Unfortunately, there is the common assumption that you could compare binary compressed
gzipped data but that fails if a newer version of a compression library implement changes
that may improve compression ratio.
I looked into the posted fix to libreoffice
that is not ideal since it will just inspect if some PNG was inserted in the document,
without actually testing if the pixels match.
Finally, quite a lot has changed in the last 2 years since those optimizations were
contributed to Fedora.
The ARM specific optimizations were ported to x86, some of the optimizations were
re-written (e.g. 0001-Neon-Optimized-hash-chain-rebase.patch) and we also added some new
optimizations for both compression (optimized insert_string, hash_slide, etc) and
decompression (read64, ARMv8 crypto enabled crc32, etc).
Those patches are hosted within Chromium's zlib
) and are part of Cronet
(Chromium Network library) that is used by quite a few Android apps like Youtube, GPhotos,
GMaps, etc (https://developer.android.com/guide/topics/connectivity/cronet
Recently Android Opensource Project (AOSP) has migrated to Chromium's zlib
which prompted me to add more unit tests as also fuzzing in Chromium's zlib.
Other projects like Node.js have also migrated to Chromium's zlib
We have around 96% of coverage for the optimizations
) and the unit tests run
as part of Chromium infrastructure on all supported OSes (e.g. Linux, OSX, Windows,
Android, Fuchsia) and architectures (aarch64, armv7, x86-32, x86-64).
All these testing and fuzzing helped to find some issues in zlib
that were properly patched.
The optimizations should yield an average boost of 120% for decompression and around 40%
for compression both for ARM and x86.
For an overview of the changes, please check 'Optimizing zlib on ARM: the power of
My recommendation today is to just use Chromium's zlib directly since that won't
require maintaining patches and you will keep in sync with future optimizations and