Profiling scrolling through my own timeline, and focusing on points where the CPU hit 100% or greater, I saw this:
(1) 50% of time spent in style calculation forced by accessing element.offsetHeight in JavaScript. > We then have JS which checks the heights of all the > stories on in the offscreen element so it can swap stories back and > forth between the two columns, to keep things sorted by time going > down the page. One sometimes pernicious effect of accessing style-related properties while changing the DOM is that you force twice (or n times) the work to happen: first, style resolves to supply your property value; then, you change the DOM, and style resolves again to account for your change. Since style resolution is generally O(n), this can easily become O(n^2) behavior. According to my measurements while scrolling my own timeline, you could make scrolling twice as buttery by removing these accesses to element.offsetHeight, or doing them on a zero-delay timer after all DOM changes. (2) 50% of time spent painting images. This is a simple speed vs quality tradeoff. If you down-sampled the images on the server, they'd download and paint much faster. Geoff _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
