3 ms·

> This is likely to put too much pressure on the CPU and memory of the decoding client as each refresh event involves a full pass through the decompression syst

• bick_nyers 5y ago
  Interesting, although it will depend on how bandwidth constrained your users are vs. their CPU/memory profile. If downloading images takes longer than decoding, it swings in favor of progressive decode. In .jxl, it is an optional feature.
• jonsneyers 5y ago
  Progressive JPEG has ~10 scans by default in libjpeg/mozjpeg. Lossy JPEG XL always allows minimal progression (2 scans, 1:8 followed by 1:1), and uses maybe 3-5 scans when encoding with more progression. In any case, I think the "costs too much cpu" argument is not really fair, since there is nothing forcing an implementation to do explicit flush/repaint at every scan. In fact, browsers will only do a refresh when cpu is _not_ the bottleneck, but network is. When cpu _is_ the bottleneck (e.g. the file is loaded from local cache), you can just decode the whole file non-progressively and have only a single refresh (just like with inherently non-progressive formats). If network is the bottleneck, then the choice is between cpu time (avoiding progressive previews to save some cpu effort) and human time (show previews so something can be shown earlier). I think human time is more valuable, by a few orders of magnitude.