I forgot to mention the case where images might be disk cached but the
size is reported asynchronously. WebKit will not do a layout before
the 250ms mark, so when you're dealing with pages that mostly come
from the cache, the layouts that end up being requested by all of the
images popping in typically beat the first actual layout (at the 250ms
mark) anyway.
dave
(hy...@apple.com)
On Apr 10, 2009, at 11:20 AM, David Hyatt wrote:
On Apr 10, 2009, at 8:51 AM, Johnny Ding wrote:
Hi all,
I have an idea about caching image's intrinsic size to improve
render performance.
We have discussed this idea in the past and discarded it for a
number of reasons, mainly:
(1) Most Web pages at this point specify an explicit size on images.
(2) This only matters in the uncached case.
(3) Layout time is completely irrelevant once you're dealing with
uncached pages.
(4) Layout time is very very small already.
We know the dynamic size change will cause the page re-layout when
rendering HTML pages. It hurts render performance. The size change
of images are usual cases for this issue. In HTML pages, The
<img> tag might not be specified width and height, or only has
specified width/height. In this case, the img's render size will
be calculated based on the intrinsic size of image-data.
Before getting the actual image data, WebKit will use default
intrinsic value (now is width:0 / height:0) to calculate the size
of renderImage object, aftering receiving the real image data, the
intrinsic size of renderImage object will be changed, the
"imageChanged" method will be called and the layout around the
renderImage could re-layout. If the renderImage object is nested
in couple of render containers, the area which need to re-layout
could be big and even the whole page could need to re-layout.
Layout is extremely optimized to deal with cases like this though.
Saying "the whole page could need to re-layout" is pretty
exaggerated. Just because elements shift around on a page, it does
not mean that they are re-laying out their contents. They are
simply moving. That is not a big deal. The cost of multiple
layouts and paints is subsumed by the networking time of loading the
images themselves anyway, so the overall time to completely load the
page isn't really increasing.
My idea is after first time requiring a image data, we use a map to
cache the intrinsic size of the image data, such as
http:///www.a.com/1.jpg 200*160 ... (additional properties)
http:///www.b.com/2.jpg 160*200 ...
Then next time one renderImage is created, we use its url of image
data to look up the previous recorded size info and set it as
default intrinsic value. I know the real intrinsic size of some
images could be changed, but so far we don't care because the value
we cached is only used as default value or you can say it's
potential value. Once we get real size from outside world, the
right value will be applied. Actually in most of times, the
previous recored intrinsic size is the real sintrinsic size. Since
we use right intrinsic size to calculate the size of renderImage
objects from first time, when real imag datas are coming, we might
not need to do lots of re-layout action. It should improve the
whole render performace of WebKit.
Also we can serialize the cached intrinsic information of images
after caching them. Then we can re-load and de-serialize the
intrinsic information when re-starting browser instance. With
reusing the cached intrinsic information, we can make the layout
faster even we don't get real image data in this new browser
instance which does not have cached image resources at that time.
Since there are too many images in the world and we have limited
resources. We should limit the number of map entries which save
cached intrinsic information.
For each entry of intrinsic info, we can have two added properties.
one is hit counter, which indicates how many times the intrinsic
info of the image in this entry has been used.
another one is timestamp, which indicates the last time of getting
intrinsic info of the image in this entry.
Once we exceed the limitation of map entries, we need to find one
entry which has the lowest hit counter (high priority) and the
earliest timestamp (old priority), then use new intrinsic
information to replace the old information in this entry.
Would you please share your comments for this idea. If there are
no major concerns on it, I am planning to file a bug and write a
patch for it.
I think this is an unnecessary optimization.
dave
(hy...@apple.com)
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
