Bug 28392 - Scrolling a Google Spreadsheet slower than Firefox (much worse on Windows)
Summary: Scrolling a Google Spreadsheet slower than Firefox (much worse on Windows)
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC All
: P2 Normal
Assignee: Nobody
Depends on:
Reported: 2009-08-17 10:14 PDT by Peter Kasting
Modified: 2009-09-08 17:29 PDT (History)
4 users (show)

See Also:

Call-graph profile on Chromium/Linux (698.69 KB, image/png)
2009-08-17 10:14 PDT, Peter Kasting
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Kasting 2009-08-17 10:14:12 PDT
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."
Comment 1 James Robinson 2009-09-08 17:29:54 PDT
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.