2012/8/14 Alpha Lam <hc...@chromium.org>: > > > 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 agree with you. > > 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. > I also wondered whether flashing of file or data uri contents is acceptable. In my opinion, it might be acceptable, because it is hard to recognize flashing in these cases too. If flashing is really unacceptable, we can turn off parallel image decoder in these case. DS Huang > Alpha > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
