[webkit-dev] Making overflow clipping cheaper
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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making overflow clipping cheaper
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 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@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 ﹆﹆﹆ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making overflow clipping cheaper
Hi Kenneth, > 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. It looks like a neat goal but not something I had in mind to be frank. I can see how we could use such a refactoring to simplify the situation but I am not sure it would be wise to do it as part of the same change: there are likely issues inside WebCore to this migration without involving the WebKit/ layer. Thanks, Julien ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making overflow clipping cheaper
On Tuesday 27 December 2011, Julien Chaffraix 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). > Wouldn't it be better to implement better searching and paint-segmentation in RenderLayers then? It could also provide the same speed up for many other big cases. Regards `Allan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making overflow clipping cheaper
> Wouldn't it be better to implement better searching and paint-segmentation in > RenderLayers then? It could also provide the same speed up for many other big > cases. That would be worth investigating more for sure (do you mind filing a bug about it?). The paint search and segmentation algorithm is very close between RenderLayer and most RenderObjects - tables being an exception here as their structure enables better searching algorithms - which means that it would benefit everyone. I haven't spend enough time looking at generic scalability issues to say if there won't be others more important bottlenecks. I still see some upsides in attacking the reduced use case of overflow clips independently of what you are proposing: * RenderLayer has become a class handling far too many tasks so moving some functionality out of it is good by itself. * RenderObject has a better knowledge of its own structure, something as generic as RenderLayer would not need to be aware of. Thanks, Julien ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making overflow clipping cheaper
I'd be careful in how I approach this. Some platforms are going to want compositing of overflow sections eventually for fast scrolling of those sections. RenderLayer has become the natural tie-in point for GraphicsLayer connections. In the future I envision overflow sections being more justified in having layers by virtue of the fact that they would always be composited. In a non-composited world, I can see why you might be tempted to yank overflow functionality out of RenderLayer, but in a composited world, having RenderLayers created for these objects makes more sense. dave (hy...@apple.com) On Dec 29, 2011, at 5:49 PM, Julien Chaffraix wrote: >> Wouldn't it be better to implement better searching and paint-segmentation in >> RenderLayers then? It could also provide the same speed up for many other big >> cases. > > That would be worth investigating more for sure (do you mind filing a > bug about it?). The paint search and segmentation algorithm is very > close between RenderLayer and most RenderObjects - tables being an > exception here as their structure enables better searching algorithms > - which means that it would benefit everyone. I haven't spend enough > time looking at generic scalability issues to say if there won't be > others more important bottlenecks. > > I still see some upsides in attacking the reduced use case of overflow > clips independently of what you are proposing: > * RenderLayer has become a class handling far too many tasks so moving > some functionality out of it is good by itself. > * RenderObject has a better knowledge of its own structure, something > as generic as RenderLayer would not need to be aware of. > > Thanks, > Julien > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making overflow clipping cheaper
> I'd be careful in how I approach this. Some platforms are going to want > compositing of overflow sections eventually for fast scrolling of those > sections. RenderLayer has become the natural tie-in point for GraphicsLayer > connections. This is something I don't want to prevent. That said it looks like my proposal (and current view on RenderLayer) is going against the current situation where RenderLayer is the only tie-in for GraphicsLayer. I don't know if splitting part of RenderLayer is totally against the goal of having that part composited. This just means that we need to change our paradigm and enable more classes to be composited. Note that the proposal is rough as there are different functionalities handled by RenderLayer (repainting, hit testing, ...) that would need to be properly patched for the new code path. > In the future I envision overflow sections being more justified in having > layers by virtue of the fact that they would always be composited. Hardware acceleration will definitely make us faster on some operations. I am concerned by the fact that this does not solve our core issue - namely RenderLayer is too generic for most cases and ends up hurting performance. As pages become more complex, those pain points will show up more and more (hit testing AFAICT is still done in software thus will not gain from accelerated composition). Thanks, Julien ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making overflow clipping cheaper
On Jan 4, 2012, at 2:36 PM, Julien Chaffraix wrote: >> namely RenderLayer is too generic for most cases and ends > up hurting performance. In what way? Overflow clips create layers, but they do not paint or hit test at the layer level unless they are self-painting layers. They only become self-painting layers if some other property is present that causes this to happen, e.g., absolute positioning. Perhaps you could point me to the specific performance problems that you're seeing that are caused by overflow and layers, since we already should be avoiding the self-painting layer code paths for overflow that doesn't need a layer for some other reason. Note I have no real objection RenderLayers using mix-ins or composition to bring in scrolling functionality. That seems sensible if that's all you're planning. I'd just like to understand the performance concerns more, since it's not clear to me what your specific performance issues are. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
