Consider that if the image is cached, the decoding cost is paid over and over and over every time the page is opened, negatively affecting power use and responsiveness, while 10% in download size is saved only once.
вт, 1 сент. 2026 г. в 09:27, Alexander Ivanov <[email protected]>: > I'm not sure why lossless decoding performance is an issue. If I'm on a > mobile device I will be more concerned downloading a huge lossless image in > the first place, the speed of decoding is irrelevant at this point. I don't > believe that it is a realistic scenario that "CDNs will externalise costs". > JXL benefits outweigh this imaginary scenario. > > On Wednesday, August 26, 2026 at 5:21:16 PM UTC+1 dev null wrote: > >> I don't see a reason to break an important feature of an image format >> just because some small amount of users might have slightly less battery >> life if they browse special sites serving a lot of lossless images. >> The vast majority of sites and CDN's deliver lossy images to users, they >> have a far greater incentive to deliver lossy images, as that's far more >> efficient for both them and the users, there is no good reason to assume >> this will meaningfully impact the average user at all. >> There is no reason to assume JXL lossless optimization won't dramatically >> improve, while you can consider the lossy encoding well optimized, lossless >> has not yet received as thorough of an optimization, and optimization for >> both is still not as mature as codecs like WebP which have been around for >> 15+ years, and have far more users. >> I personally have a great use of JXL lossless images as I have huge >> archives of lossless images on my personal home server, but considering I >> like to view most of those images in browsers on my devices, I have been >> blocked from converting my archive, and have been waiting for several years >> for Chrome to add JXL support, especially lossless. >> I would be heartbroken to still not be able to use JXL's excellent >> lossless compression, after all these years of waiting. >> >> On Wednesday, August 26, 2026 at 5:18:15 PM UTC+2 Sergey Davidoff wrote: >> >>> It is not clear if significant further optimization is even possible. >>> libjxl, the original highly optimized C++ implementation, was also 20x >>> slower to decode than WebP in my measurements. This indicates that we're >>> more likely than not in the realm of diminishing returns already. Rushing >>> the stabilization in hopes that further *dramatic* optimizations *might* >>> be possible seems reckless. >>> >>> ср, 26 авг. 2026 г. в 10:32, Philip Jägenstedt <[email protected]>: >>> >>>> I think this is a real risk, but we should expect adoption to ramp up >>>> quite slowly, and that there will be time to optimize. The usage can be >>>> seen at https://webstatus.dev/features/jpegxl or >>>> https://chromestatus.com/metrics/webfeature/timeline/popularity/418 >>>> (same underlying data) and should start rizing from ~0 only after this >>>> reaches stable. >>>> >>>> On Tue, Aug 25, 2026 at 10:04 PM Sergey Davidoff <[email protected]> >>>> wrote: >>>> >>>>> What I am concerned about is CDNs using lossless JPEG XL to cut their >>>>> network costs, and externalize those costs by degrading battery life for >>>>> all users with recent enough browsers. They are financially incentivized >>>>> to >>>>> do so, and that is why I am so concerned about giving them the >>>>> opportunity. >>>>> >>>>> вт, 25 авг. 2026 г. в 20:16, Birk Hirdman <[email protected]>: >>>>> >>>>>> Moreover, the encoder can be configured to prioritize decoding speed >>>>>> over maximum compression -- for example, setting --faster_decoding 1 does >>>>>> not change the compressed size significantly, but doubles decoding speed. >>>>>> >>>>>> >>>>>> Then perhaps only fast-decoding lossless mode should be supported in >>>>>> web browsers. A 7.5x slowdown instead of 15x might be excusable, >>>>>> depending >>>>>> on the use case. >>>>>> >>>>>> >>>>>> Surely websites can select compression options that fit their use >>>>>> cases? Perhaps all that is needed is to change the default in libjxl's >>>>>> CLI >>>>>> tool to use faster_decoding=1. >>>>>> >>>>> -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABaUXi60JqaUwh7bftoUZB1Rja1C7XMgAF0Eo6xmhvxPt4DVMw%40mail.gmail.com.
