A progress bar for something that’s loading in parallel over the same network, to give the user an idea of how much the delay is?
During the week, well, it would be unfair to call it LinkedInified, but it can often feel like a somewhat higher tier of that sort of strata. Plenty of good stuff in there still, but much more “serious business”.
This is how we defeat skynet: by sending each other pictures of cats.
That's basically the server telling the client 'That data I just sent you, well now replace it with this new thing'.
No JavaScript needed, and can work with plain http and jpeg
Obviously the demonstrations that rely on server-side timing don't work through archive.org.
You can use Service Worker to emulate a slow connection :)
But if better compression for storage or you can verify progressive serves faster then it is of course a benefit.
I guess the point I am making is that most people think: I heard it's somehow better so lets use it.
And it is possible to losslessly transcode JPEG to progressive.
Lossless transcoding to JPEG XL gives even more space savings though.
Still the question is, does it help? Trying to access an average web app will probably take minutes before the browser may even see an image. If you do everything possible to render reasonably fast on very slow speeds, then progressive is nice. On a fast connection I don't think the average user will notice the difference.
But this is clever - just smash them together. Low frequency of one image concatenated with high frequency from another. This works surprisingly well!
Easy enough to add a delay() each frame if your server is python/nodejs/PHP/whatever
Edit: the format also supports region-of-interest decoding and I suspect you can make some cool maps or fractal images with both features. But I think they're not quite prioritizing implementing that right now.
I was about to say: I'm sure I've seen it work a t some point? I imagine it's a valuable thing to add for the web though. It would be really cool if you could use the same image source for thumbnail and full image, and the browser both just figures out how much to download based on pixel size and can resume previously partially downloaded images.
And yeah, the tiling isn't implemented anywhere yet, jxl doesn't really get enough funding for that. But it'll be really cool once it does since it also makes it really useful for giant images of geographic data. I don't know if it combines with streaming downloads as well, but it would be crazy cool if we effectively got OpenSeaDragon[0] support inside an image format
> so playback is entirely dependent on network delay
Ultimately true, but I set up my server to send each "frame" separately, with a fixed delay between each. Each frame is small so unless your network is unusually slow, the timing is set by my server.