[chromium] Move draw time properties out of *LayerChromium to CCLayerImpl
Created attachment 83431 [details] Patch
This patch is (in essence) a strict subset of https://bugs.webkit.org/show_bug.cgi?id=54047. IMO it's big enough and conflict-likely enough to land by itself, but small enough to be a low-risk landing so I'd like to get it in before there is too much more surgery on these files. Most of the lines touched are changes that switch to use a getter/setter rather than setting member variables directly. Conceptually this patch doesn't do much except prepare for splitting the draw responsibilities away from what currently exists as the LayerChromium tree. The patch at https://bugs.webkit.org/show_bug.cgi?id=54047 shows what this looks like after the update and draw steps are divided more cleanly in LayerRendererChromium's internals.
Vangelis, could you do the unofficial review of this patch?
Comment on attachment 83431 [details] Patch Is the plan to also rename RenderSurfaceChromium to something like ccRenderSurface and move it to the cc directory? Is there any reason you call the new class CCLayerImpl instead of plain CCLayer ? Like you mention in the description, there's still a bunch of code that will need to change to break the connections between CCLayers and LayerChromium's but I think this is a fine first step.
(In reply to comment #4) > (From update of attachment 83431 [details]) > Is the plan to also rename RenderSurfaceChromium to something like ccRenderSurface and move it to the cc directory? Yup, that will happen as well. It seemed premature to do that yet as it adds more churn and RenderSurfaceChromium is still being used directly by some of the LayerChromium subclasses. > Is there any reason you call the new class CCLayerImpl instead of plain CCLayer ? > Nat pointed out that it makes more sense to name the interface we exposed to the rest of WebKit CCLayer and have CCLayerImpl be the compositor's internal implementation. IOW GraphicsLayerChromium will have a set of CCLayers and set properties on them, etc, and only the compositor internals will ever have knowledge of CCLayerImpl. > Like you mention in the description, there's still a bunch of code that will need to change to break the connections between CCLayers and LayerChromium's but I think this is a fine first step.
I could imagine doing a similar change to LayerRendrerChromium too, as a subsequent patch perhaps.
So everyone is OK with this?
(In reply to comment #7) > So everyone is OK with this? No complaints here. It makes a lot of sense to commit this large but low-risk change first.
Comment on attachment 83431 [details] Patch Thumbs up in that case.
Committed r79659: <http://trac.webkit.org/changeset/79659>
http://trac.webkit.org/changeset/79659 might have broken Leopard Intel Debug (Build)