Hi fellow hackers, while investigating some slowness related to painting big HTML tables [1], RenderLayer's painting code path was pointed out as the source of slowness. The problem stems from RenderLayer not being aware of the peculiarities of the underlying RenderObject (RenderTableSection implements painting using a binary search to find out which cells to paint instead of trying all cells like RenderLayer).
Looking closely, it seems that the current code path is sub-optimal. Adding an overflow clip on an element should be a cheap operation but it ends up not being the case. This is because RenderLayer needs to handle a lot of different use cases (transforms, opacity, z-index...) [2]. I have spend some time thinking about how to make clipping a cheaper operation and it looks like we could factor out most of the scrolling logic (scroll offset, scrollbars, ScrollableArea) into a light-weight object. This object would be orthogonal to RenderLayer. The painting would go through "normal" (ie without layer) code path that can already handle the clipping. As a first step, I took over [3] (splitting ScrollableArea out of RenderLayer) but would like to get some feedbacks whether this proposal sounds like something we would like to do or there are some core issues I missed. Any comments welcome! Thanks, Julien [1] https://bugs.webkit.org/show_bug.cgi?id=75001 [2] I would argue that RenderLayer itself is a big memory overhead but that's another debate. [3] https://bugs.webkit.org/show_bug.cgi?id=60305 _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
