Bug 94957 – [chromium] Have RenderSurface create and add its own generated RenderPass

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Dana Jansens]

[chromium] Have RenderSurface create and add its own generated RenderPass

[Dana Jansens]

Created attachment 160455 [details]
Patch

[Adrienne Walker]

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

[Adrienne Walker]

(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.

[Adrienne Walker]

Comment on attachment 160455 [details]
Patch

R=me.

[Dana Jansens]

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.

[Dana Jansens]

Created attachment 160773 [details]
Patch for landing

[WebKit Review Bot]

Comment on attachment 160773 [details]
Patch for landing

Clearing flags on attachment: 160773

Committed r126790: <http://trac.webkit.org/changeset/126790>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.