[chromium] Have RenderSurface create and add its own generated RenderPass
Created attachment 160455 [details] Patch
Comment on attachment 160455 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=160455&action=review > Source/WebCore/platform/graphics/chromium/cc/CCLayerTreeHostImpl.cpp:287 > + renderSurfaceLayer->renderSurface()->appendRenderPasses(frame); Aren't you eventually going to want to call appendRenderPasses on a DelegatingLayer? Maybe this would be better if it initially went through the layer who could then call CCRenderSurface::appendRenderPasses internally. This would also give you some nice symmetry where if a layer adds a pass, then it is also the one that will get called back later to appendQuads (if the pass isn't cached). > Source/WebCore/platform/graphics/chromium/cc/CCLayerTreeHostImpl.h:97 > + // CCRenderPassSink implementation. > + virtual void appendRenderPass(PassOwnPtr<CCRenderPass>); OVERRIDE
(In reply to comment #2) > (From update of attachment 160455 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=160455&action=review > > > Source/WebCore/platform/graphics/chromium/cc/CCLayerTreeHostImpl.cpp:287 > > + renderSurfaceLayer->renderSurface()->appendRenderPasses(frame); > > Aren't you eventually going to want to call appendRenderPasses on a DelegatingLayer? Maybe this would be better if it initially went through the layer who could then call CCRenderSurface::appendRenderPasses internally. This would also give you some nice symmetry where if a layer adds a pass, then it is also the one that will get called back later to appendQuads (if the pass isn't cached). Actually, now that I think about it, it's more complicated than that. This is a good refactoring first step, and I can wait to see what the delegating layer will have to change to make it work.
Comment on attachment 160455 [details] Patch R=me.
Comment on attachment 160455 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=160455&action=review >>> Source/WebCore/platform/graphics/chromium/cc/CCLayerTreeHostImpl.cpp:287 >>> + renderSurfaceLayer->renderSurface()->appendRenderPasses(frame); >> >> Aren't you eventually going to want to call appendRenderPasses on a DelegatingLayer? Maybe this would be better if it initially went through the layer who could then call CCRenderSurface::appendRenderPasses internally. This would also give you some nice symmetry where if a layer adds a pass, then it is also the one that will get called back later to appendQuads (if the pass isn't cached). > > Actually, now that I think about it, it's more complicated than that. This is a good refactoring first step, and I can wait to see what the delegating layer will have to change to make it work. Yeh, we only call append on layers that own RenderSurfaces, which the DelgatedRendererLayer does not usually do. >> Source/WebCore/platform/graphics/chromium/cc/CCLayerTreeHostImpl.h:97 >> + virtual void appendRenderPass(PassOwnPtr<CCRenderPass>); > > OVERRIDE Oops thanks.
Created attachment 160773 [details] Patch for landing
Comment on attachment 160773 [details] Patch for landing Clearing flags on attachment: 160773 Committed r126790: <http://trac.webkit.org/changeset/126790>
All reviewed patches have been landed. Closing bug.