[webkit-dev] Making overflow clipping cheaper

[Julien Chaffraix]

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