3 ms·
> Displaying a JPEG in multiple passes uses significantly more CPU No, it's not. It has become a meme mainly because libjpeg-turbo v1 didn't have optimizations
by pornel 7y ago
> Displaying a JPEG in multiple passes uses significantly more CPU
No, it's not. It has become a meme mainly because libjpeg-turbo v1 didn't have optimizations for progressive coding. It's been fixed in v2. Progressive rendering keeps state and incrementally updates it. Browsers throttle refresh speed to avoid expensive edge cases. There has been a lot of investment in browsers to make compositing dirt cheap.
There are ways to make incomplete JPEG decoding even faster, e.g. decode just DC passes (that's 1/64th of memory and no IDCT), but the feedback I've got from maintainer of libjpeg-turbo and from browser vendors is that it's at best "nice to have" territory and the progressive JPEG overhead is a non-issue in practice.
- londons_explore 7y agoMy experience tuning the Chromium rendering pipeline doesn't match this. The actual jpeg decode is fast, but all the rest of the drawing and compositing required is sloooow. For one thing, the skia graphics library has to reprocess the drawlist for all things in the layer, and the drawlist (including the elements outside the clipping rect of the image) needs to be serialised and sent to the GPU process each time for every update. Perhaps I'm missing something tho.
- untog 7y agoIt sounds like OP (no offence to them) is missing the context? Decoding a JPEG itself can be super fast but if laying out every element that overlaps that JPEG is slow the a progressive JPEG is still going to cause speed issues.