3 ms·
I'm just guessing, but bumping a library version to include new code cam integrating a separate library might be the differentiating factor.
by junon 1y ago
I'm just guessing, but bumping a library version to include new code cam integrating a separate library might be the differentiating factor.
- jchw 1y agoThe zstd library is already included by most major browsers since it is a supported content encoding. Though I guess that does leave out Safari, but Safari should probably support Zstd for that, too. (I would've preferred that over Brotli, but oh well.)
- eru 1y agoBtw, could you 'just' use no compression on this level in the PNG, and let the transport compression handle it? So on paper (and on disk) your PNG would be larger, but the number of bits transmitted would be almost the same as using Zstd? EDIT: similarly, your filesystem could handle the on-disk compression. This might work for something like PNG, but would work less well for something like JPG, where the compression part is much more domain specific to image data (as far as I am aware).
- jchw 1y agoIf there is a particular reason why that wouldn't work, I'm not aware of it. Seems like you would eat a very tiny cost for deflate literal overhead (a few bytes per 65,535 bytes of literal data?) but maybe you would wind up saving a few bytes from also compressing the headers.
- GoblinSlayer 1y ago5 bytes per block or 0.000076 overhead.
- JyrkiAlakuijala 1y agozstd compresses less, so you wait a bit more for your data