4.4

Swift PNG 4.4 adds gzip compression and decompression tools to the LZ77 module, and updates the documentation with examples of how to use gzip compression in your app.

Internally, Swift PNG 4.4 also adopts nested protocols (SE-0404), which makes the documentation easier to navigate but should be an API-transparent change, as all of these protocols were already informally namespaced via typealiases.

Swift PNG 4.4 requires Swift 5.10 or newer.

Why use Swift PNG’s gzip implementation?

Swift PNG’s native Swift gzip implementation is not as fast as some existing C libraries which are found on many systems. However, a lot of optimization work went into the LZ77 module long ago, and the Swift version should not be significantly slower than an equivalent C library.

Applications that compress large volumes of data and do little else may be better off calling a system C library instead of using LZ77. However the complexity of marshaling data through a C library can often be a disincentive to using compression in more peripheral use cases, and having a convenient, portable Swift library available that still performs reasonably well can help make applications more efficient overall.

Why is the gzip library still part of Swift PNG?

The compression backend was written long ago exclusively for Swift PNG, and the decision to expose it to external clients was only made recently. The PNG library helps us test the correctness of the gzip backend, as the PNG format is little more than a wrapper around an LZ77 data stream.

Applications that depend on the LZ77 target only will not pull in PNG-related code.

How can I help?

Rewriting the project’s benchmarks to use the more-modern package-benchmark framework would help us gain better visibility into how the library is performing relative to system C libraries. PRs that add benchmark integrations to the project are likely to be merged.