On 31/08/2020 23:05, Adenilson Cavalcanti wrote:
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.
Wow, thanks a lot for going above and beyond to proof my naive assumption was indeed right. :)
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.
Yeah, but the reported purpose of that unit test is to verify that an image is embedded, not to verify the correctness of the PNG-generating code. Lets hope that there's other tests in the suite that cover the latter.
[...] _______________________________________________ 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
