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 https://github.com/madler/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 match. 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 (https://codepen.io/Savago/full/qBZXXOv) 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 (https://gerrit.libreoffice.org/c/core/+/101329/3/sw/qa/extras/htmlexport/htmlexport.cxx), 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 (https://chromium.googlesource.com/chromium/src/third_party/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 (https://cs.android.com/android/platform/superproject/+/master:external/zlib/METADATA) 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 (https://github.com/nodejs/node/blob/master/deps/zlib/OWNERS). We have around 96% of coverage for the optimizations (https://bugs.chromium.org/p/chromium/issues/detail?id=1032721#c21) 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 (https://source.chromium.org/chromium/chromium/src/+/master:third_party/zlib/patches/), 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 NEON': https://docs.google.com/presentation/d/1xdDQ0LgVpdD2-gDyUXlLfN2JYoXFR98pmn8FhuaNaOA/edit?usp=sharing 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 security fixes. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
