Switch to zlib-ng for performance & newer libpng compatibility

[gitoss]

Since I seem to depend on the built-in libs with Visual Studio (I cannot get previously build libs to link with libavif due to some obscure "linking module flags: IDs have conflicting values" error:

A switch from old school zlib to zlib ng would enhance png performance, plus (probably) allow for libpng versions >1.6.40 (1.7 is is beta...). It's supposed a drop-in replacement with -DZLIB_COMPAT=ON

https://github.com/zlib-ng/zlib-ng https://github.com/AOMediaCodec/libavif/blob/main/cmake/Modules/LocalZlibpng.cmake

[wantehchang]

I also considered zlib alternatives before because zlib's CMakeLists.txt did not support Windows well and the patch I sent to the zlib maintainer (both by email and as a pull request) was not reviewed. Another zlib fork worth considering is Chrome's zlib fork: https://chromium.googlesource.com/chromium/src/third_party/zlib

[gitoss]

Another zlib fork worth considering is Chrome's zlib fork: https://chromium.googlesource.com/chromium/src/third_party/zlib

Interesting, I didn't know that.

zlib-ng looks appealing because of the SIMD code, but it might still be more hassle to configure even with the documentation provided. The chrome zlib looks simple, because there is no documenation (on the git site) at all :->

It probably doesn't matter that much unless encoding or decoding very big png files with high compression ... but it might still happen, I'm exporting Lightroom => PNG => avif/heic because PNG "just works".

Alas, being stuck with the old libpng doesn't look appealing at all... https://github.com/madler/zlib/issues/1019

[wantehchang]

@gitoss I'd like to know why you are interested in zlib alternatives. From your earlier comment, I think the reasons are:

1. Better performance
2. Upgrade to libpng > v1.6.40

Is this correct?

Regarding the second reason, I am wondering how libpng 1.6.41-1.6.44 could be released without a zlib release containing https://github.com/madler/zlib/commit/f1f503da85d52e56aae11557b4d79a42bcaa2b86.

The only reason I considered zlib alternatives was to fix a Windows build issue (https://github.com/madler/zlib/pull/818). We are working around that Windows build issue in our LocalZlibpng.cmake file. Note: I think that issue has been fixed on the zlib main branch in another way, based on the two target_include_directories() calls shown in https://github.com/madler/zlib/commit/f1f503da85d52e56aae11557b4d79a42bcaa2b86. It seems that I can abandon https://github.com/madler/zlib/pull/818 and write a new pull request to remove the two include_directories() calls.

[gitoss]

1. Better performance
2. Upgrade to libpng > v1.6.40

Yes, that is correct. The libpng issue probably will get solved sooner or later, but with bulk image encoding every bit of more performance helps - so why not use what's for 'free' by switching libs or optimizing compiler flags.

I've even compiled pgo-optimized versions of svt-av1, plus using faster maths functions - which makes a great difference in libavif, very like much more than a faster libpng.

[Neustradamus]

@gitoss, @wantehchang: About CMake and Zlib, please do PR or comment pulls/tickets...

I have done a ticket which is not complete:

• https://github.com/madler/zlib/issues/831

[gitoss]

@gitoss, @wantehchang: About CMake and Zlib, please do PR or comment pulls/tickets... I have done a ticket which is not complete:

Looking at the ticket, changing the lib from zlib to zlib-ng or something else is probably better than trying to cmake-fix zlib.

Even the zlib maintainer stats that zlib forks have improved cmake support - which he would like to have backported with pull requests from the forks - which probably won't happen anytime soon or at all.