Re: Regarding switching to zlib-ng in contribs

Hi,

I think discussions should happen in an issue (Feature Request) as doing 
it here will probably have less visibility, but we'll see.

On 11/04/2025 03:36, Fatih Uzunoğlu wrote:
> Hello,
> 
> I have tried to search for previous discussions regarding switching to 
> zlib-ng in the mailing list and GitLab, but could not find. My 
> understanding is that zlib-ng has been maintained better than the 
> original zlib. It reportedly is much faster, and compresses slightly 
> better.
> 
> This is relevant for the Qt interface a lot, because all resources 
> (which includes the compiled shader bytecode "qsb" files, and all QML 
> files that are not compiled by `qmlcachegen`), and possibly the QML 
> bytecode too outside the resource system (when `qmlcachegen` is used) 
> are compressed and all of them need to be decompressed synchronously in 
> bulk during start-up. High decompression speed would make at least the 
> interface start faster.

There's only one way to settle this: actual numbers for the time it 
takes to start between the two.

> I previously attempted to introduce zstd (as Qt does not provide this 
> itself) in !4791 (https://code.videolan.org/videolan/vlc/-/ 
> merge_requests/4791), which became the default since Qt 6. However, I 
> decided to not proceed with that because 1) the license of it does not 
> seem too clear and 2) it needs to be built two times (one for host, used 
> for compression by rcc; one for target (when cross compiled), used for 
> decompression by qtbase), and this is not nice when zlib still needs to 
> be built anyway for other contribs.

IMO we should have zstd. My understanding is that it's much faster to 
compress/decompress but it doesn't compress very well. For this 
particular use case it seems to better candidate.

The license is pretty clear, it's BSD: 
https://github.com/facebook/zstd/blob/dev/LICENSE

> It seems that we are still not interested in using zstd. So a drop-in 
> replacement for zlib that boosts the performance would be nice.
> 
> Any opinions on this? My biggest worry is regarding security, can zlib- 
> ng be considered as secure as zlib? Are the maintainers well established 
> and trustworthy? If this is a problem, maybe the Chromium fork of zlib 
> (`zlib-chromium`) can be another alternative, which I assume would be 
> secure enough. There are some notes regarding the Chromium fork here: 
> https://github.com/madler/zlib/issues/346.

My issue with zlib-ng is that it doesn't produce the same compression as 
the official zlib which can be an issue when you generate a file and 
checks the hash. But we don't do that so it's not an issue here.

If you look at the releases 
(https://github.com/zlib-ng/zlib-ng/releases) it seems they often fix 
logical bugs. I'm not sure how more reliable it is to the official zlib.

> Alternatively, I have also read about zlib-rs, but Rust can be a 
> problem. Do we even demand a Rust toolchain?

We do but I'm not sure C/C++ contribs should depend on a rust contrib. 
At least not a hard dependency.

> I have found some benchmarks here: https://github.com/zlib-ng/zlib-ng/ 
> issues/1486, https://trifectatech.org/blog/zlib-rs-is-faster-than-c/.
> 
> Sincerely,
> Fatih Uzunoğlu
> 
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel

_______________________________________________
vlc-devel mailing list
To unsubscribe or modify your subscription options:
https://mailman.videolan.org/listinfo/vlc-devel