75001 2011-12-21 01:59:03 -0800 Painting on a table with overflow: hidden cells is very slow 2023-10-03 00:39:06 -0700 1 1 1 Unclassified WebKit Layout and Rendering 528+ (Nightly build) All All NEW https://bugs.webkit.org/show_bug.cgi?id=73715 http://dglazkov.github.com/performance-tests/biggrid.html P2 Normal --- 88386 89389 89899 85678 88464 88570 88888 73714 92258 1 jchaffraix webkit-unassigned dglazkov eric jamesr simon.fraser thorton tomhudson tonikitoo oldest_to_newest 525196 0 jchaffraix 2011-12-21 01:59:03 -0800 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. 644011 1 jchaffraix 2012-06-07 15:56:07 -0700 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. 651680 2 jchaffraix 2012-06-18 13:42:15 -0700 (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. 722957 3 eric 2012-09-18 11:58:49 -0700 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.