> > With respect to new image formats such as JPEG XL, that means we have to > look comprehensively at many factors: compression performance across a > broad range of images; is the decoder fast, allowing for speedy rendering > of smaller images; are there fast encoders, ideally with hardware support, > that keep encoding costs reasonable for large users; can we optimize > existing formats to meet any new use-cases, rather than adding support for > an additional format; do other browsers and OSes support it? >
JPEG XL is much faster than AVIF - JPEG XL encoding is about three times as fast as AVIF [1 <https://cloudinary.com/blog/the-case-for-jpeg-xl#lossy_compression_performance>, 2 <https://avif.io/blog/comparisons/avif-vs-jpegxl/#speed>]. JPEG XL supports progressive decoding and JPEG transcoding, unlike AVIF. JPEG XL is available in Firefox Nightly (under a flag) and it is being implemented by Facebook, Adobe, Intel, Krita, The Guardian, Cloudinary, Shopify and more companies. So there is definitely enough interest from the industry. If JPEG XL was implemented in Chromium, it would quickly boost adoption by CDNs and replace JPEG in a short time thanks to lossless JPEG transcoding capability. So what was the real rationale for dropping JPEG XL support? As for the WebAssembly implementation, the jxl_dec.wasm file is 821 KB [3 <https://github.com/GoogleChromeLabs/squoosh/blob/dev/codecs/jxl/dec/jxl_dec.wasm>] (290 KB gzipped) and it can only run after DOM tree is ready and JS is parsed, so it will never be as performant as the native JPEG XL decoder and it will not work when JS is disabled. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5e416872-c2e3-4ade-b540-fd2cddb975e4n%40chromium.org.
