Regarding switching to zlib-ng in contribs
Fatih Uzunoğlu <[email protected]> Fri, 11 Apr 2025 04:36:28 +0300
| Newsgroups | gmane.comp.video.videolan.vlc.devel |
|---|---|
| Message-ID | <AM6PR0202MB33682C5B60AB1EF647745AB2AFB62@AM6PR0202MB3368.eurprd02.prod.outlook.com> |
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. 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. 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. Alternatively, I have also read about zlib-rs, but Rust can be a problem. Do we even demand a Rust toolchain? 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
smime.p7s
(application/pkcs7-signature, 4.6 KB) - not displayed