[webkit-dev] Making overflow clipping cheaper

[Kenneth Rohde Christiansen]

Hi Julien,

As you probably are aware, some mobile ports paint their own overlay
scroll indicators and do scrolling on the UI side (div overflow using
a separate layer)

Would it be possible to refactor this code in a way that it would
simplify the code paths for these ports? maybe avoiding it altogether.
Currently there is a lot of scrolling code in FrameView/ScrollView etc
as well which we avoid call when delegatesScrolling() is true.

Cheers,
Kenneth

On Tue, Dec 27, 2011 at 5:50 PM, Julien Chaffraix
<julien.chaffraix at gmail.com> wrote:
> 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
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev



-- 
Kenneth Rohde Christiansen
Senior Engineer
Nokia Mobile Phones, Browser / WebKit team
Phone  +45 4093 0598 / E-mail kenneth at webkit.org

http://codeposts.blogspot.com ﹆﹆﹆