[Webkit-unassigned] [Bug 28392] New: Scrolling a Google Spreadsheet slower than Firefox (much worse on Windows)

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=28392

           Summary: Scrolling a Google Spreadsheet slower than Firefox
                    (much worse on Windows)
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Layout and Rendering
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: pkasting at google.com
                CC: hyatt at apple.com


Created an attachment (id=34975)
 --> (https://bugs.webkit.org/attachment.cgi?id=34975)
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."

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.