3 ms·

They have not closed a narrower bug about the lossless JPEG compression: https://bugs.chromium.org/p/chromium/issues/detail?id=1109698 https://bugs.chromium.org

They have not closed a narrower bug about the lossless JPEG compression: https://bugs.chromium.org/p/chromium/issues/detail?id=1109698 https://bugs.chromium.org/p/chromium/issues/detail?id=110969... I think it's a legitimately different tradeoff because the recompression is not like a new lossy format--less code, plus you don't need the whole ecosystem to move, big sites and CDNs can transparently start using it--but still substantial (22% on JPEG content out there). And by being very CPU-light it fills a fairly large gap where people are not ready to use AVIF, which needs either dedicated hardware or tons of CPU to encode. One thing this is right about is a WASM polyfill is interesting. With that and a ServiceWorker, you can make the recompression pretty transparent (right-click saves a .jpg) but still save your 22%. The performance penalty of doing it in WASM is a question, but it's definitely possible.

mike_hearn 4y ago
The problem with using WASM is that because of their cache segmentation, every site that wants to render JXL would have to redownload the WASM decoder from scratch, and every page load that wants to render it would presumably have to JITC it from scratch too. The WASM model doesn't seem to be a good replacement for browser plugins. Amusingly, when Chrome killed off plugins one of the rationales they gave was "reducing code complexity". The enormous bloat in the code and HTML5 specs that followed did many things, but reducing Chrome's code complexity isn't one of them.
- edflsafoiewq 4y ago
  The problem with using WASM is it doesn't create an ecosystem where you can save the JXL, open it in a editor, upload it yourself, etc. like a normal image file.
- twotwotwo 4y ago
  A JXL contributor says full JXL (not just the recompression) can fit in 174kB, and thinks a smaller version could fit in 50: https://news.ycombinator.com/item?id=33414678 https://news.ycombinator.com/item?id=33414678 If you have large JPEGs it's not hard to earn the bandwidth cost back. I am definitely curious about other aspects of WASM performance including speed on first run.

mike_hearn 4y ago

The problem with using WASM is that because of their cache segmentation, every site that wants to render JXL would have to redownload the WASM decoder from scratch, and every page load that wants to render it would presumably have to JITC it from scratch too. The WASM model doesn't seem to be a good replacement for browser plugins. Amusingly, when Chrome killed off plugins one of the rationales they gave was "reducing code complexity". The enormous bloat in the code and HTML5 specs that followed did many things, but reducing Chrome's code complexity isn't one of them.

edflsafoiewq 4y ago
The problem with using WASM is it doesn't create an ecosystem where you can save the JXL, open it in a editor, upload it yourself, etc. like a normal image file.
twotwotwo 4y ago
A JXL contributor says full JXL (not just the recompression) can fit in 174kB, and thinks a smaller version could fit in 50: https://news.ycombinator.com/item?id=33414678 https://news.ycombinator.com/item?id=33414678 If you have large JPEGs it's not hard to earn the bandwidth cost back. I am definitely curious about other aspects of WASM performance including speed on first run.