2012/8/13 KwangYul Seo <sk...@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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
