3 ms·
Agreed, +1 for browser makers to make progressive JPEG loading not look like a dog just barfed the original image
by ronyfadel 7y ago
Agreed, +1 for browser makers to make progressive JPEG loading not look like a dog just barfed the original image
- lvh 7y agoIt'd be neat if there was an easy way to combine progressive JPEG loading with aggressive CSS blur filters, maybe. I think onload fires when the progressive JPEG is done, so perhaps you could have the onload JS disable the blur?
- DagAgren 7y agoDo modern browsers even support progressive display of JPEGs? I have not seen it happen in years and years.
- dspillett 7y agoI expect they do. It might just be that people aren't often encoding JPEGs such that they can take advantage of the support (or that your link is generally fast enough that you don't see an intermediate render of the data).
- jrochkind1 7y agoYes.
- londons_explore 7y agoIn the blink rendering engine, partial rendering of a progressive jpeg is pretty much the lowest priority task for CPU time. That means unless you have a very slow network and very fast CPU, you will never see half rendered progressive jpegs. That's the right design decision, because rendering a progressive jpeg repeatedly is rather expensive - as well as redecoding the whole jpeg, you also need to re-render any text or effects overlaying the jpeg, and recomposite the frame. And then you're gonna have to do all that work again when a few more bytes of progressive jpeg arrive from the network...