NEW 75001
Painting on a table with overflow: hidden cells is very slow 
https://bugs.webkit.org/show_bug.cgi?id=75001
Summary Painting on a table with overflow: hidden cells is very slow
Julien Chaffraix
Reported 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.
Attachments
Add attachment proposed patch, testcase, etc.
Julien Chaffraix
Comment 1 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.
Julien Chaffraix
Comment 2 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.
Eric Seidel (no email)
Comment 3 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.
Note You need to log in before you can comment on or make changes to this bug.