[webkit-dev] Making overflow clipping cheaper

[David Hyatt]

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
(hyatt at 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 at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev