[webkit-dev] An idea to improve render performance by caching image-data's intrinsic size

[David Hyatt]

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
(hyatt at apple.com)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090410/1a377007/attachment.html>