Painting on a table with overflow: hidden cells is very slow

• Component: Layout and Rendering
• Status: NEW ---

[Julien Chaffraix]

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.

[Julien Chaffraix]

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]

(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)]

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.