3 ms·

Images don't have to be updated many times if the data arrives fast enough. When re-rendering is throttled, you get progressive rendering only when the network

by pornel 8y ago

Images don't have to be updated many times if the data arrives fast enough. When re-rendering is throttled, you get progressive rendering only when the network is relatively slow, and don't spend extra CPU time when the data arrives quickly. Even though progressive is more costly than baseline, they're both relatively cheap. JPEG was designed when CPUs were clocked at 25Mhz. Progressive JPEGs are significantly smaller (thanks to having a Huffman table per scan), and they're the default in all image optimization tools and services (MozJPEG, ImageOptim, Cloudflare's Polish, etc.). For a long time progressive JPEGs had a slow path in libjpeg-turbo, but this has been improved recently, and there's still room for more optimization. For example, a DC-only preview could be decoded and rendered very cheaply (approx 1/64th cost in CPU and memory). We're planning to contribute to libjpeg to make progressive rendering more optimized.

londons_explore 8y ago
> When re-rendering is throttled, you get progressive rendering only when the network is relatively slow, I suspect this is the issue... In a modern multi-process browser and OS, it's exceptionally hard to know if it's worth making a low-res render, or if there is more data sitting in kernel/application buffers somewhere which hasn't yet made it to the renderer due to CPU pressure. For example, if you have an event queue for un-gzipping and another for jpeg decompressing, you should never do any jpeg work unless the gzip queue is empty. Every event queue in the system needs to correctly prioritize every step in the rendering process, otherwise work is wasted rendering a progressive jpeg more times than necessary.
- pornel 8y ago
  Buffering actually works in your favor, because when the client reads the buffered data, it's more likely to get the whole file in one go. Browsers already have delays and throttling for painting and relayout, because incremental rendering of HTML and DOM updates create lots of similar problems. I don't know if browsers do it, but moving progressive image decoding to a very-low-priority thread would be an easy solution that solves 99% of the problem (nothing gets blocked, you get as much progressive rendering as you can spare CPU time). It would be hard to be absolutely optimal about this, but my point is that in practice it's one or two extra renders, not O(n^2) you'd expect from synchronous redecoding on every byte received.

by pornel 8y ago

londons_explore 8y ago

> When re-rendering is throttled, you get progressive rendering only when the network is relatively slow, I suspect this is the issue... In a modern multi-process browser and OS, it's exceptionally hard to know if it's worth making a low-res render, or if there is more data sitting in kernel/application buffers somewhere which hasn't yet made it to the renderer due to CPU pressure. For example, if you have an event queue for un-gzipping and another for jpeg decompressing, you should never do any jpeg work unless the gzip queue is empty. Every event queue in the system needs to correctly prioritize every step in the rendering process, otherwise work is wasted rendering a progressive jpeg more times than necessary.

pornel 8y ago
Buffering actually works in your favor, because when the client reads the buffered data, it's more likely to get the whole file in one go. Browsers already have delays and throttling for painting and relayout, because incremental rendering of HTML and DOM updates create lots of similar problems. I don't know if browsers do it, but moving progressive image decoding to a very-low-priority thread would be an easy solution that solves 99% of the problem (nothing gets blocked, you get as much progressive rendering as you can spare CPU time). It would be hard to be absolutely optimal about this, but my point is that in practice it's one or two extra renders, not O(n^2) you'd expect from synchronous redecoding on every byte received.