> 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 [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
