Scrolling a Google Spreadsheet slower than Firefox (much worse on Windows)

• Component: Layout and Rendering
• Status: NEW ---

[Peter Kasting]

Created attachment 34975 [details]
Call-graph profile on Chromium/Linux

Originally filed as http://crbug.com/19215 , but determined to affect WebCore in general, not just the Chromium port.

Test these steps first in Safari 4/Win, then read on below.

(1) Visit docs.google.com
(2) Create a new spreadsheet
(3) Hit the "+" button in the lower left and add 500 more rows
(4) Try to use the scrollbar on the right to scroll up and down.  Note sluggishness.
(5) Open same spreadsheet (or repeat same steps) in Firefox and notice snappy performance.

Shrinking the window size doesn't ameliorate this problem.  The problem is visible (but less so) even with shorter spreadsheets.

One investigator who profiled Chromium/Win doing this testcase found a profile like the following:

"6.81%  WebCore::RenderBox::mapLocalToContainer
5.72%  WebCore::RenderBox::computeRectForRepaint
5.21%  WebCore::RenderTable::colToEffCol
4.07%  WebCore::compareBorders
4.07%  WebCore::RenderBox::offsetFromContainer
(I've got pretty same results from both VTune's and V8's sampling profilers.)

Compiled JavaScript only occupies individual ticks."

Another developer profiled Chromium/Linux and produced a graph of the results, which I've attached.  The interesting bits are at the bottom.  He also shared the following details:

"By running Safari both on Mac and Windows, I can say that in the described use case, Safari is much slower on Windows. On Mac, Safari is slower than Firefox (which is scrolling just instantly), but at least, it's bearable. Chromium is slow on both platforms, so it seems like a computationally expensive WebKit's code is boosted by h/w acceleration on Mac."

[James Robinson]

I did some investigation of this and it appears that in WebKit the page's onscroll handler is causing a nontrivial amount of deferred layout to happen which causes the deferred paint to be delayed by 100+ms after the scroll happens.  The sequence looks like this (WinXP in VMWare, Chromium, 500 row spreadsheet, each entry is a separate dispatch off the event loop):

0.) scroll event fires, handler set scrollTop on some element
1.) deferred layout runs for ~25ms
2.) more deferred layout, another ~25ms
3.) ... repeat 3 more times
6.) paint finally happens (~20ms)

It makes sense that the hot paths in the profiler are all in layout - there's a very large table in the page that apparently has its layout invalidated by javascript.  The odd thing is that FireFox doesn't exhibit this slowdown - either they aren't doing this layout, they are doing it after the paint, or the page is not invalidating layout for FFx while scrolling.