W3C home > Mailing lists > Public > public-houdini@w3.org > February 2015

Re: Image decoding off the main thread

From: Simon Fraser <smfr@me.com>
Date: Wed, 11 Feb 2015 07:54:00 -0800
Cc: public-houdini@w3.org
Message-id: <6FF68847-1E30-4370-9E21-44BAC2A28E84@me.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
On Feb 11, 2015, at 7:46 am, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 2/11/15 4:09 AM, Dean Jackson wrote:
>> Three days late, but I finally thought of something I wish I'd proposed at the meeting: image decoding on a background thread.
> What is the proposal exactly?  Gecko does this already, for example....
>> For this I guess we'd need some attribute on IMG/Image/HTMLImageElement that would indicate that the main thread doesn't have to decode this image.
> Why would the main thread "have" to decode the image, exactly?
>> I'm not sure if we need a new "ready" event, or just assume that "load" means loaded and decoded.
> In Gecko "load" means loaded and decoded, iirc.  Except possibly for cases where we decide to do the decoding lazily to start with…

WebKit only decodes the image when it’s first painted, which can block painting for over 200ms for large images on slow hardware. We wouldn’t want to eagerly decode all images because not all of them will get painted, and decoding involves allocating backing store.

I think what web authors really need is an “eager decode” flag; something that triggers up-front decoding of an image so that it doesn’t block at paint time.

The danger, of course, is that authors could abuse this and cause their page to use huge amounts of image memory, so it should only be a hint.

Received on Wednesday, 11 February 2015 15:54:31 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 15:54:31 UTC