News for hackers. Stuff that matters.
Re:BlurHash: Algorithm to generate compact representation of... by asah on Thursday February 20, 2020 @09:54AM (#22375437)
How did this compare with progressive JPEG ?
Re:BlurHash: Algorithm to generate compact representation of... by lvh on Thursday February 20, 2020 @09:59AM (#22375477)
I think the biggest difference is in visual effect. A progressive JPEG looks pretty terrible at first, whereas a blurred image may look preferable even though it technically has less information.
Re:BlurHash: Algorithm to generate compact representation of... by ronyfadel on Thursday February 20, 2020 @10:12AM (#22375570)
Agreed, +1 for browser makers to make progressive JPEG loading not look like a dog just barfed the original image
Re:BlurHash: Algorithm to generate compact representation of... by lvh on Thursday February 20, 2020 @10:19AM (#22375627)
It'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?
Re:BlurHash: Algorithm to generate compact representation of... by DagAgren on Thursday February 20, 2020 @10:23AM (#22375659)
Do modern browsers even support progressive display of JPEGs? I have not seen it happen in years and years.
Re:BlurHash: Algorithm to generate compact representation of... by londons_explore on Friday February 21, 2020 @04:53AM (#22382046)
In 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...

Re:BlurHash: Algorithm to generate compact representation of... by dspillett on Thursday February 20, 2020 @12:38PM (#22376820)
I 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).
Re:BlurHash: Algorithm to generate compact representation of... by jrochkind1 on Thursday February 20, 2020 @01:36PM (#22377382)
Yes.
Re:BlurHash: Algorithm to generate compact representation of... by dspillett on Thursday February 20, 2020 @12:34PM (#22376792)
If the full images are large, and you have a number of them on the page (a gallery age for instance) some will remain empty boxes until others are completely loaded, as the browser limits the number of concurrent connections to each host.

IIRC the limit is most commonly 6. So if you have 7 or more images the 7th will not even partially download until the 1st has downloaded in full.

With this method, the small blurred images will load before any of the larger ones so you should see them all relatively immediately, absolutely immediately if encoded in the HTTP stream as data rather than being retrieved with an extra HTTP request, before any of the larger images start to transfer.

Re:BlurHash: Algorithm to generate compact representation of... by DagAgren on Thursday February 20, 2020 @10:22AM (#22375653)
In addition to the aesthetic effect, this is available immediately, while progressive JPEG will still require additional data to be loaded from the server.