Bug 75001 - Painting on a table with overflow: hidden cells is very slow
Summary: Painting on a table with overflow: hidden cells is very slow
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL: http://dglazkov.github.com/performanc...
Keywords:
Depends on: 88386 89389 89899 85678 88464 88570 88888
Blocks: 73714 92258
  Show dependency treegraph
 
Reported: 2011-12-21 01:59 PST by Julien Chaffraix
Modified: 2017-07-18 08:29 PDT (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Julien Chaffraix 2011-12-21 01:59:03 PST
Seen on the benchmark: http://dglazkov.github.com/performance-tests/biggrid.html. If you toggle overflow: hidden and scroll on the table, you can see that painting takes several times more time that without overflow: hidden (for example by looking at the WebInspector timeline).

RenderTableSection implements an optimization during painting where it finds the dirtied cells to paint using a binary search on the rows and columns (see RenderTableSection::paintObject). When we toggle overflow: hidden, the painting goes through the RenderLayer path. However there is no such optimization and we spend a lot of time trying to repaint layers that are not dirty (or even worse off-screen). This bug may be related to bug 73715 but it looks like there is more to the other bug (composition is involved for example).

As a side note, hit testing has exactly the same issue.
Comment 1 Julien Chaffraix 2012-06-07 15:56:07 PDT
For the record, when scrolling on the page on a 10,000 * 100 table with overflow: hidden, the painting used to take ~255 ms (for 2048 x 256). We are now down to ~45 ms.

Painting has been sped up but the core issue still remains: we should have visit only the visible cells instead of all the cells in the table.
Comment 2 Julien Chaffraix 2012-06-18 13:42:15 PDT
(In reply to comment #1)
> For the record, when scrolling on the page on a 10,000 * 100 table with overflow: hidden, the painting used to take ~255 ms (for 2048 x 256). We are now down to ~45 ms.

Bug 88888 landed another performance optimization. It makes us not visit any of the cells in biggrid.html particular case. This brings the paint time to ~6ms in the same conditions.

> Painting has been sped up but the core issue still remains: we should have visit only the visible cells instead of all the cells in the table.

The optimization is somewhat limited and could be improved upon. First hit-testing is still sluggish but also the optimization relies on having _no_ self-painting-descendants which means that if you have one, you don't reap any performance benefit.

I am keeping this bug open to track more of the fixes.
Comment 3 Eric Seidel (no email) 2012-09-18 11:58:49 PDT
bug 92258 is another bug on the topic of this benchmark.  Perhaps it should be duped against this one or both related to some more generic meta-bug.