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
