[webkit-dev] Status of multithreaded image decoding

[Alpha Lam]

2012/8/13 KwangYul Seo <skyul at company100.net>

>
>> This approach is probably safe (as far as I know) but would have the
>> downside of an extra pass over the whole render tree, or else overhead of
>> maintaining an up-to-date list of rendered images; and it would happen very
>> close to painting.
>>
>>
I agree on getting actual numbers. I suspect there will be some gain though
the limiting factor is the slowest-to-decode image in the viewport.


> Unfortunately, yes. Because of the lazy nature of image decoding, we don't
> have much time for decoding before images need to be painted. So we skip
> image decoding (and just trigger decoding in the background) in the first
> paint pass and update the decoded images later.
>
>
>>
>>
I looked at the demo video and honestly I don't find experience
particularly bad with your approach. The argument here is that when a page
is fully cached and images will be painted with an instantaneous white
region, I think though caching is an implementation detail of both WebCore
and the browser so user doesn't really know if a page is 100% cached. Think
about an evicted image would have a similar effect.

I think the expectation is different for web (e.g. http, https) and always
available content (e.g. file, data uri) from a developer / user's
perspective.

Alpha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120813/54b7ff95/attachment-0001.html>