Add the ubercomp DelegatedRendererLayer.

Add the ubercomp DelegatedRendererLayer.

This adds a layer that owns a set of RenderPasses with DrawQuads, and is
able to insert those RenderPasses and DrawQuads into the current frame
during CCLayerTreeHostImpl::calculateRenderPasses().

The layer owns whatever quads/passes you give to it, and copies them
with modifications as needed into the current frame via the QuadSink.

Quads from the layer's root RenderPass are merged into its target
RenderPass, with the transform and opacity being modified if needed.
Other RenderPasses are inserted into the frame as-is, with RenderPass
ids being adjusted to not collide with any other RenderPasses in the
frame, and using a scheme that allows the layer to reverse-lookup
its own copy of a RenderPass from the id it generated.

Moved from: https://bugs.webkit.org/show_bug.cgi?id=94145

Tests:
CCDelegatedRendererLayerImplTestSimple.AddsContributingRenderPasses
CCDelegatedRendererLayerImplTestSimple.AddsQuadsToContributingRenderPasses
CCDelegatedRendererLayerImplTestSimple.AddsQuadsToTargetRenderPass
CCDelegatedRendererLayerImplTestSimple.QuadsFromRootRenderPassAreModifiedForTheTarget
CCDelegatedRendererLayerImplTestOwnSurface.AddsRenderPasses
CCDelegatedRendererLayerImplTestOwnSurface.AddsQuadsToContributingRenderPasses
CCDelegatedRendererLayerImplTestOwnSurface.AddsQuadsToTargetRenderPass
CCDelegatedRendererLayerImplTestOwnSurface.QuadsFromRootRenderPassAreNotModifiedForTheTarget

BUG=123445
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=157700

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=157794

[danakj, 2012-09-14 01:44:54]

I've implemented the changed in CCLTHImpl to not go thru all the of the vector
looking for relevent RenderPasses.

Also fixed up the test to make sure we drop the renderpasses on context lost
(and made us actually do that), thanks piman.

I removed the layer from the "make sure we free textures" test, cuz the layer
doesn't want to free any textures. Instead, it should release them back to the
child compositor - I added a FIXME to this point.

[enne (OOO), 2012-09-14 17:33:00]

LGTM, with one nit:

https://codereview.chromium.org/10916307/diff/1/cc/CCLayerTreeHostImpl.cpp
File cc/CCLayerTreeHostImpl.cpp (right):

https://codereview.chromium.org/10916307/diff/1/cc/CCLayerTreeHostImpl.cpp#ne...
cc/CCLayerTreeHostImpl.cpp:302: CCDelegatedRendererLayerImpl*
delegatedRendererLayer = static_cast<CCDelegatedRendererLayerImpl*>(*it);
The static cast is a little dodgy.  If you want to go down this path rather than
the previous one, can you add a comment in the CCLayerImpl API that
hasContributingDelegatedRenderPasses now means "is derived from
CCDelegatedRendererLayerImpl?"

[danakj, 2012-09-14 17:37:10]

https://codereview.chromium.org/10916307/diff/1/cc/CCLayerTreeHostImpl.cpp
File cc/CCLayerTreeHostImpl.cpp (right):

https://codereview.chromium.org/10916307/diff/1/cc/CCLayerTreeHostImpl.cpp#ne...
cc/CCLayerTreeHostImpl.cpp:302: CCDelegatedRendererLayerImpl*
delegatedRendererLayer = static_cast<CCDelegatedRendererLayerImpl*>(*it);
Oh, good point. What do you think of making the firstContributingRenderPassId
and nextContributingRenderPassId functions virtual on CCLayerImpl instead?

[enne (OOO), 2012-09-14 18:11:35]

On 2012/09/14 17:37:10, danakj wrote:
> https://codereview.chromium.org/10916307/diff/1/cc/CCLayerTreeHostImpl.cpp
> File cc/CCLayerTreeHostImpl.cpp (right):
> 
>
https://codereview.chromium.org/10916307/diff/1/cc/CCLayerTreeHostImpl.cpp#ne...
> cc/CCLayerTreeHostImpl.cpp:302: CCDelegatedRendererLayerImpl*
> delegatedRendererLayer = static_cast<CCDelegatedRendererLayerImpl*>(*it);
> Oh, good point. What do you think of making the firstContributingRenderPassId
> and nextContributingRenderPassId functions virtual on CCLayerImpl instead?

Hmm, that does leak yet more logic into the CCLayerImpl API (which is not
small), but I like that better.

[danakj, 2012-09-14 18:31:13]

On 2012/09/14 18:11:35, enne wrote:
> On 2012/09/14 17:37:10, danakj wrote:
> > https://codereview.chromium.org/10916307/diff/1/cc/CCLayerTreeHostImpl.cpp
> > File cc/CCLayerTreeHostImpl.cpp (right):
> > 
> >
>
https://codereview.chromium.org/10916307/diff/1/cc/CCLayerTreeHostImpl.cpp#ne...
> > cc/CCLayerTreeHostImpl.cpp:302: CCDelegatedRendererLayerImpl*
> > delegatedRendererLayer = static_cast<CCDelegatedRendererLayerImpl*>(*it);
> > Oh, good point. What do you think of making the
firstContributingRenderPassId
> > and nextContributingRenderPassId functions virtual on CCLayerImpl instead?
> 
> Hmm, that does leak yet more logic into the CCLayerImpl API (which is not
> small), but I like that better.

Ok, thanks. Done! PTAL if you like, will be waiting on webkit rolls to CQ.

[enne (OOO), 2012-09-14 19:37:23]

Thanks! LGTM still.  :)

[commit-bot: I haz the power, 2012-09-19 22:19:40]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/10916307/8001

[commit-bot: I haz the power, 2012-09-19 22:45:11]

Retried try job too often for step(s) interactive_ui_tests, jingle_unittests,
gpu_unittests, base_unittests, sync_integration_tests, sql_unittests,
chrome_frame_unittests, content_unittests, safe_browsing_tests, ipc_tests,
mini_installer_test, cacheinvalidation_unittests, remoting_unittests,
browser_tests, net_unittests, installer_util_unittests, chrome_frame_net_tests,
check_deps, crypto_unittests, unit_tests, nacl_integration, media_unittests,
content_browsertests, printing_unittests, sync_unit_tests

[commit-bot: I haz the power, 2012-09-19 22:45:16]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/10916307/17003

[commit-bot: I haz the power, 2012-09-19 23:28:18]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/10916307/16003

[commit-bot: I haz the power, 2012-09-20 01:01:55]

Sorry for I got bad news for ya.
Compile failed with a clobber build.
Your code is likely broken or HEAD is junk. Please ensure your
code is not broken then alert the build sheriffs.
Look at the try server FAQ for more details.

[commit-bot: I haz the power, 2012-09-20 01:01:59]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/10916307/9028

[commit-bot: I haz the power, 2012-09-20 03:38:01]

Change committed as 157700

[jamesr, 2012-09-20 04:42:13]

On 2012/09/20 03:38:01, I haz the power (commit-bot) wrote:
> Change committed as 157700

https://chromiumcodereview.appspot.com/10940002/ landed literally 1 rev before
this and so this broke the build and got reverted.  So sorry!  You just need to
change cc::CCDelegatedRendererLayerImpl::appendRenderPassQuads to not call get()

[danakj, 2012-09-20 14:41:41]

Hah such timing! OwnPtr should be proud of itself for causing such a
ruckus :p Thanks for the pointer.

On Thu, Sep 20, 2012 at 12:42 AM,  <[email protected]> wrote:
> On 2012/09/20 03:38:01, I haz the power (commit-bot) wrote:
>>
>> Change committed as 157700
>
>
> https://chromiumcodereview.appspot.com/10940002/ landed literally 1 rev
> before
> this and so this broke the build and got reverted.  So sorry!  You just need
> to
> change cc::CCDelegatedRendererLayerImpl::appendRenderPassQuads to not call
> get()
>
> https://chromiumcodereview.appspot.com/10916307/

[commit-bot: I haz the power, 2012-09-20 14:51:39]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/10916307/28001

[commit-bot: I haz the power, 2012-09-20 17:26:59]

Change committed as 157794