Timothy Nikkel
unread,
Aug 24, 2026, 7:15:09 AM (yesterday) Aug 24
to dev-pl...@mozilla.org
As of Firefox 157 I intend to turn JPEG XL decoding on by default on all platforms. It has been developed behind image.jxl.enabled, which today is on by default on Nightly only, and has had a Firefox Labs checkbox on every channel since 152. The decoder is jxl-rs, in Rust.
Timothy Nikkel
unread,
Aug 24, 2026, 7:37:11 AM (yesterday) Aug 24
to dev-pl...@mozilla.org
一丝
unread,
4:22 AM (15 hours ago) 4:22 AM
to dev-pl...@mozilla.org, tni...@mozilla.com
Is Animated JXL currently supported?
Timothy Nikkel
unread,
4:40 AM (15 hours ago) 4:40 AM
to 一丝, dev-pl...@mozilla.org
Yes. Animated jxl is supported.
Tim
Sergey Davidoff
unread,
6:40 AM (13 hours ago) 6:40 AM
to dev-pl...@mozilla.org, tni...@mozilla.com
I am concerned about lossless JPEG XL performance. In my measurements it is 30x slower to decode than lossless WebP, in exchange for a 10% reduction in file size. This is a questionable trade-off, especially on laptops and phones where it could drain battery and degrade user experience.
I suggest shipping only lossy JPEG XL in Firefox 157, and considering lossy JPEG XL format separately.
Measurement methodology
jxl-rs from git https://github.com/libjxl/jxl-rs on commit 775837f57dfe4294d89c1c6317dd91a1ed8d3cfa compiled with 'cargo build --release'
converted to WebP with 'cwebp -lossless', to JPEG XL with 'cjxl -d 0'
Both decoders running in single-threaded mode to measure total CPU time taken with 'taskset -c 0'.
$ hyperfine --warmup 5 'taskset -c 0 target/release/jxl_cli --speedtest 55_Cancri_e_Final_1_30.jxl' 'taskset -c 0 dwebp 55_Cancri_e_Final_1_30.png.webp'
For reference, libjxl's djxl tool is 20x slower than WebP in the same measurement. So it doesn't look like further optimizations to the Rust code could help, but would not change the overall calculus.