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
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.
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
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