3 ms·

Unfortunately, there's no format yet that's both significantly better, and somewhat standard. There are PIK, FLIF and FUIF, all of which have very nice progres

by pornel 8y ago

Unfortunately, there's no format yet that's both significantly better, and somewhat standard. There are PIK, FLIF and FUIF, all of which have very nice progressive loading, but they're totally experimental with no plan in sight to get them standardized. The closest to becoming standard (or de-facto standard) is AVIF, AV1-based HEIF sibling. The compression there is great: half size of WebP, so regardless whether it's progressive or not, it's going to load fast. In the meantime there's still room to improve rendering of progressive JPEG. The blockiness of early progressive stages is mostly an artifact of implementation in libjpeg. The smoothing could be much better, so it can look more elegant.

microcolonel 8y ago
> It's going to load fast Minor nitpick: on kinda-average U.S. home internet, with a medium-low power laptop decoding in software, the actual time to load an image could be a wash because of decode time, even with the dramatically-improved software AV1 decoders.
- pornel 8y ago
  With newer codecs the CPU becomes a factor indeed. This mostly makes JS/WASM polyfills for these formats unattractive. However, using native decoders with proper SIMD optimizations shouldn't be too bad. dav1d achieves 100fps in full HD on SSE3 CPUs and A11. Only mass-market Android phones are really worrying, so it may be possible to do content negotiation that is aware of trade-off between the device and network speed.
  - microcolonel 8y ago
    > dav1d achieves 100fps in full HD on SSE3 CPUs and A11 That's with multiple threads, the actual frame latency is much worse than 1/100s on a typical SSE3 CPU, if you're just decoding a single frame/image on a single thread. Decoding each image with multiple threads, you'll run into issues with throughput. That's not to say there aren't times it's worth it, and hardware decoders will start to become a reasonable way to do this (especially on Linux/Chrome OS, where it should now take less time to wire things like this up thanks to v4l2 m2m devices), but regardless there will continue to be a crossover between decode-dominant and network-dominant image loading.

by pornel 8y ago

microcolonel 8y ago

> It's going to load fast Minor nitpick: on kinda-average U.S. home internet, with a medium-low power laptop decoding in software, the actual time to load an image could be a wash because of decode time, even with the dramatically-improved software AV1 decoders.

pornel 8y ago
With newer codecs the CPU becomes a factor indeed. This mostly makes JS/WASM polyfills for these formats unattractive. However, using native decoders with proper SIMD optimizations shouldn't be too bad. dav1d achieves 100fps in full HD on SSE3 CPUs and A11. Only mass-market Android phones are really worrying, so it may be possible to do content negotiation that is aware of trade-off between the device and network speed.
- microcolonel 8y ago
  > dav1d achieves 100fps in full HD on SSE3 CPUs and A11 That's with multiple threads, the actual frame latency is much worse than 1/100s on a typical SSE3 CPU, if you're just decoding a single frame/image on a single thread. Decoding each image with multiple threads, you'll run into issues with throughput. That's not to say there aren't times it's worth it, and hardware decoders will start to become a reasonable way to do this (especially on Linux/Chrome OS, where it should now take less time to wire things like this up thanks to v4l2 m2m devices), but regardless there will continue to be a crossover between decode-dominant and network-dominant image loading.