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

Re: Image decoding off the main thread

From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Wed, 11 Feb 2015 11:12:57 -0500
Message-ID: <54DB7F89.5010403@mit.edu>
To: Simon Fraser <smfr@me.com>
CC: public-houdini@w3.org
On 2/11/15 10:54 AM, Simon Fraser wrote:
> 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.

Sure.  Gecko has various heuristics for deciding which images to decode 
eagerly and which ones to decode lazily, but primarily we eagerly decode 
things that are visible in the viewport before we've started painting 
(painting triggers a decode, of course; I'm not sure whether it forces a 
sync decode or allows a background one with a repaint when done).

http://hg.mozilla.org/mozilla-central/file/38058cb42a0e/dom/base/nsImageLoadingContent.cpp#l233 
has some relevant comments.

> I think what web authors really need is an “eager decode” flag

When would a web author use this flag?

> 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.

Indeed.  And what should be the heuristic for ignoring this hint?  And 
why can the negation of this heuristic not be used as a decoding heuristic?

I'm willing to be convinced that we need a page-controllable thing here, 
but I think it's worth thinking through why it's really needed.

-Boris
Received on Wednesday, 11 February 2015 16:13:27 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 16:13:28 UTC