Timothy Nikkel 未读，2026年8月24日，上午4:15:09（昨天） 8月24日发给 dev-pl...@mozilla.org截至 Firefox 157，我打算在所有平台上默认启用 JPEG XL 解码。它在 image.jxl.enabled 后开发，目前在 Nightly 上默认开启，并且自 152 以来在每个渠道都有 Firefox Labs 复选框。解码器是 jxl-rs，使用 Rust 编写。默认开启的错误报告：https://bugzilla.mozilla.org/show_bug.cgi?id=2065096 标准：ISO/IEC 18181，https://www.iso.org/standard/85066.html 标准机构：ISO/IEC 平台覆盖：所有 偏好设置：image.jxl.enabled 标准立场： https://github.com/mozilla/standards-positions/issues/522（中立）TAG 审查：https://github.com/w3ctag/design-reviews/issues/633（对关注问题表示满意）原型意图：https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/53b4e3e0-5eee-4768-a1ba-b069e1e85244n%40mozilla.org 其他浏览器：Safari 在 2023 年的 17.0 版本中发布了此功能。Chrome 在 #enable-jxl-image-format 后启用同样的 Rust 库，目前尚无发布意向。自原型意图提出以来的变化：性能是在原型意图线程中提到的一个问题。jxl-rs 0.6.0 发布，支持多线程解码，我们的补丁预计将很快上线，挂钩并启用多线程解码。结合这些补丁，我在多种大小的相同图片上进行了五种格式的解码基准测试：在我的机器上，我们略微领先于 Safari（使用 C++ libjxl）。与我们其他的图像格式解码器相比，JXL 在大图像上的表现相近，但在小图像上差距较大。它与我们其他图像格式和 Blink 的 JXL 实现具有相同的功能，包括动画和渐进显示。唯一的例外是 HDR：HDR 图像显示为 SDR，和我们支持的其他格式相同，但我们的 JXL 色调映射远胜于其他图像格式。Safari 既没有渐进处理也没有动画。wpt jpegxl 目录覆盖了在位深、alpha、灰度、CMYK、颜色管理、方向和编码工具等方面的解码正确性，以及图像使用的 HTML 和 CSS 方式。在 wpt 无法表达的地方，我添加了 gecko 测试：约 30 个 gtests 用于分块和增量解码、动画帧计数、解码过程中的降采样和损坏文件、mochitests 用于渐进渲染和遥测、reftests 和解码基准测试，这些都会报告给 Perfherder。模糊测试团队在 nightly 版本启用前已经对 jxl 进行了模糊测试，并且他们将在我打开偏好设置之前再次对解码器进行模糊测试。Timothy Nikkel Timothy Nikkel 未读，2026年8月24日，上午4:37:11（昨天） 8月24日发给 dev-pl...@mozilla.org 一丝 未读，上午1:22（10 小时前） 上午1:22 发给 dev-pl...@mozilla.org, tni...@mozilla.com 动画 JXL 当前支持吗？Timothy Nikkel 未读，上午1:40（10 小时前） 上午1:40 发给 一丝, dev-pl...@mozilla.org 是的。支持动画 jxl。Tim Sergey Davidoff 未读，上午3:40（8 小时前） 上午3:40 发给 dev-pl...@mozilla.org, tni...@mozilla.com 我对无损 JPEG XL 的性能表示担忧。在我的测试中，它的解码速度比无损 WebP 慢 30 倍，而文件大小仅减少 10%。这是一种值得怀疑的权衡，尤其是在可能耗尽电池并降低用户体验的笔记本电脑和手机上。我建议在 Firefox 157 中仅发布有损 JPEG XL，并单独考虑有损 JPEG XL 格式。测量方法：来自 git 的 jxl-rs https://github.com/libjxl/jxl-rs，提交 775837f57dfe4294d89c1c6317dd91a1ed8d3cfa，通过 'cargo build --release' 编译转换为 WebP 通过 'cwebp -lossless'，转换为 JPEG XL 通过 'cjxl -d 0'。两个解码器均在单线程模式下运行，以测量用 'taskset -c 0' 所用的总 CPU 时间。$ 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' 基准测试 1：taskset -c 0 target/release/jxl_cli --speedtest 55_Cancri_e_Final_1_30.jxl 平均时间 ± σ：20.632 s ± 0.061 s [用户：20.605 s，系统：0.027 s] 范围（最小…最大）：20.549 s…20.743 s 10 次运行 基准测试 2：taskset -c 0 dwebp 55_Cancri_e_Final_1_30.png.webp 平均时间 ± σ：667.0 ms ± 2.2 ms [用户：449.5 ms，系统：217.5 ms] 范围（最小…最大）：664.3 ms…670.1 ms 10 次运行 总结：taskset -c 0 dwebp 55_Cancri_e_Final_1_30.png.webp 的运行速度比 taskset -c 0 target/release/jxl_cli --speedtest 55_Cancri_e_Final_1_30.jxl 快 30.93 ± 0.14 倍。作为参考，libjxl 的 djxl 工具在相同测量中比 WebP 慢 20 倍。因此，似乎进一步优化 Rust 代码将无济于事，但不会改变整体计算结果。回复所有人 回复作者 转发