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

Johnny Ding jnd at google.com
Fri Apr 10 06:51:54 PDT 2009

Hi all,

I have an idea about caching image's intrinsic size to improve render
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
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

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

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
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.


Best Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090410/76480cd0/attachment.html>

More information about the webkit-dev mailing list