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

[David Hyatt]

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
(hyatt at 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
> (hyatt at apple.com)
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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