cc: Fork OverlayCandidate to CALayerOverlay

cc: Fork OverlayCandidate to CALayerOverlay

Create a CALayerOverlay which encapsulates all of the state that we can
use to represent a Overlay as a CALayer so far. Since this is much more
than can be represented by hardware overlays, fork this from the overlay
code.

Add a method to the OverlayValidator to indicate if using CALayers is
appropriate on a particular platform at a particular time.

Add a ProcessForCALayers method to OverlayProcessor, which, if
successful, replaces all quads with CALayers, and removes the overlay
for the backbuffer.

Of note is that many more DrawQuad features may be used by CALayers
(e.g, 3D transforms, nontrivial clipping) in the future.

Remove the AllOrNothing strategy, since this will be taking its place.

BUG=533690
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/35db390a4fe9bef22036e69683cdbcce0c6f9a49
Cr-Commit-Position: refs/heads/master@{#360163}

[ccameron, 2015-11-01 09:58:31]

ccameron@chromium.org changed reviewers:
+ alexst@chromium.org, reveman@chromium.org

[ccameron, 2015-11-01 09:58:32]

This sets up the foundation for the Mac-specific overlay-like path that we
discussed in
https://codereview.chromium.org/1394403002/

I'm keeping this very close to the overlay code (in particular, it shares the
OverlayProcess) intentionally -- these are highly related functions, shouldn't
be applied at the same time, and interact (e.g, the main system overlay goes
away if you go all-CALayer).

[ccameron, 2015-11-12 05:05:02]

Description was changed from

==========
cc: Fork OverlayCandidate to CALayerDrawQuad

Create a CALayerDrawQuad which encapsulates all of the state that we can
use to represent a DrawQuad as a CALayer. Since this is much more than
can be represented by hardware overlays, fork this from the overlay
code.

Leave this disabled, as the GL API to enable this isn't ready yet.

Remove the AllOrNothing strategy, since this will be taking its place.

BUG=533690
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
cc: Fork OverlayCandidate to CALayerOverlay

Create a CALayerOverlay which encapsulates all of the state that we can         
                    
use to represent a Overlay as a CALayer so far. Since this is much more
than can be represented by hardware overlays, fork this from the overlay        
                    
code.
                                                                                
                    
Add a method to the OverlayValidator to indicate if using CALayers is
appropriate on a particular platform at a particular time.

Add a ProcessForCALayers method to OverlayProcessor, which, if
successful, replaces all quads with CALayers, and removes the overlay
for the backbuffer.

Of note is that many more DrawQuad features may be used by CALayers
(e.g, 3D transforms, nontrivial clipping) in the future.

Remove the AllOrNothing strategy, since this will be taking its place.          
                    

BUG=533690
==========

[ccameron, 2015-11-12 05:05:18]

This is ready to go now. Ptal.

[alexst (slow to review), 2015-11-12 14:36:18]

https://codereview.chromium.org/1430813002/diff/100001/cc/output/ca_layer_ove...
File cc/output/ca_layer_overlay.cc (right):

https://codereview.chromium.org/1430813002/diff/100001/cc/output/ca_layer_ove...
cc/output/ca_layer_overlay.cc:18: bool FromIOSurfaceQuad(ResourceProvider*
resource_provider,
const ResourceProvider? I don't see anything changing it. ditto below.

https://codereview.chromium.org/1430813002/diff/100001/cc/output/ca_layer_ove...
File cc/output/ca_layer_overlay.h (right):

https://codereview.chromium.org/1430813002/diff/100001/cc/output/ca_layer_ove...
cc/output/ca_layer_overlay.h:25: unsigned contents_resource_id;
I wonder if we could fork things a bit further downstream and refactor the code
a bit.

I made the original overlay candidate struct intentionally small and limited in
scope with the expectation that we could grow it as needed by all platforms.
Things like background color and matrix transform are not out of place there, it
would be nice to branch into platform code as late as possible.

It's not a major objection, I would be fine with current code, but I can't shake
the feeling it could stay a bit more generic in earlier stages.

[ccameron, 2015-11-12 17:31:47]

https://codereview.chromium.org/1430813002/diff/100001/cc/output/ca_layer_ove...
File cc/output/ca_layer_overlay.cc (right):

https://codereview.chromium.org/1430813002/diff/100001/cc/output/ca_layer_ove...
cc/output/ca_layer_overlay.cc:18: bool FromIOSurfaceQuad(ResourceProvider*
resource_provider,
On 2015/11/12 14:36:18, alexst (slow to review) wrote:
> const ResourceProvider? I don't see anything changing it. ditto below.

It's true -- ResourceProvider has lots of const-correctness issues (see
GetResourceType, GetResourceTextureTarget, IsOverlayCandidate, et al). Probably
worth fixing, but might be a big change to roll into this one.

https://codereview.chromium.org/1430813002/diff/100001/cc/output/ca_layer_ove...
File cc/output/ca_layer_overlay.h (right):

https://codereview.chromium.org/1430813002/diff/100001/cc/output/ca_layer_ove...
cc/output/ca_layer_overlay.h:25: unsigned contents_resource_id;
On 2015/11/12 14:36:18, alexst (slow to review) wrote:
> I wonder if we could fork things a bit further downstream and refactor the
code
> a bit.
> 
> I made the original overlay candidate struct intentionally small and limited
in
> scope with the expectation that we could grow it as needed by all platforms.
> Things like background color and matrix transform are not out of place there,
it
> would be nice to branch into platform code as late as possible.
> 
> It's not a major objection, I would be fine with current code, but I can't
shake
> the feeling it could stay a bit more generic in earlier stages.

I was going in this direction at first, but back in
https://codereview.chromium.org/1394403002/, we decided to do a fork at around
this level.

The CALayer representation of an overlay is very different from the hardware
overlay planes (CALayers don't even have pixel rects -- they have floating-point
size and then a 3D transform matrix), so merging the two would be fairly
difficult. I also wanted to reuse OverlayCandidate::FromDrawQuad, but there
ended up being very little to share.

That said, when we add Wayland and/or DirectCompositing support, we may finally
see a way to merge these.

[alexst (slow to review), 2015-11-12 18:58:20]

On 2015/11/12 17:31:47, ccameron wrote:
>
https://codereview.chromium.org/1430813002/diff/100001/cc/output/ca_layer_ove...
> File cc/output/ca_layer_overlay.cc (right):
> 
>
https://codereview.chromium.org/1430813002/diff/100001/cc/output/ca_layer_ove...
> cc/output/ca_layer_overlay.cc:18: bool FromIOSurfaceQuad(ResourceProvider*
> resource_provider,
> On 2015/11/12 14:36:18, alexst (slow to review) wrote:
> > const ResourceProvider? I don't see anything changing it. ditto below.
> 
> It's true -- ResourceProvider has lots of const-correctness issues (see
> GetResourceType, GetResourceTextureTarget, IsOverlayCandidate, et al).
Probably
> worth fixing, but might be a big change to roll into this one.
> 
>
https://codereview.chromium.org/1430813002/diff/100001/cc/output/ca_layer_ove...
> File cc/output/ca_layer_overlay.h (right):
> 
>
https://codereview.chromium.org/1430813002/diff/100001/cc/output/ca_layer_ove...
> cc/output/ca_layer_overlay.h:25: unsigned contents_resource_id;
> On 2015/11/12 14:36:18, alexst (slow to review) wrote:
> > I wonder if we could fork things a bit further downstream and refactor the
> code
> > a bit.
> > 
> > I made the original overlay candidate struct intentionally small and limited
> in
> > scope with the expectation that we could grow it as needed by all platforms.
> > Things like background color and matrix transform are not out of place
there,
> it
> > would be nice to branch into platform code as late as possible.
> > 
> > It's not a major objection, I would be fine with current code, but I can't
> shake
> > the feeling it could stay a bit more generic in earlier stages.
> 
> I was going in this direction at first, but back in
> https://codereview.chromium.org/1394403002/, we decided to do a fork at around
> this level.
> 
> The CALayer representation of an overlay is very different from the hardware
> overlay planes (CALayers don't even have pixel rects -- they have
floating-point
> size and then a 3D transform matrix), so merging the two would be fairly
> difficult. I also wanted to reuse OverlayCandidate::FromDrawQuad, but there
> ended up being very little to share.
> 
> That said, when we add Wayland and/or DirectCompositing support, we may
finally
> see a way to merge these.

Fair enough. This looks good, but let me take another pass to make sure I didn't
miss any details.

[reveman, 2015-11-13 17:07:44]

On 2015/11/12 at 18:58:20, alexst wrote:
> On 2015/11/12 17:31:47, ccameron wrote:
> >
https://codereview.chromium.org/1430813002/diff/100001/cc/output/ca_layer_ove...
> > File cc/output/ca_layer_overlay.cc (right):
> > 
> >
https://codereview.chromium.org/1430813002/diff/100001/cc/output/ca_layer_ove...
> > cc/output/ca_layer_overlay.cc:18: bool FromIOSurfaceQuad(ResourceProvider*
> > resource_provider,
> > On 2015/11/12 14:36:18, alexst (slow to review) wrote:
> > > const ResourceProvider? I don't see anything changing it. ditto below.
> > 
> > It's true -- ResourceProvider has lots of const-correctness issues (see
> > GetResourceType, GetResourceTextureTarget, IsOverlayCandidate, et al).
Probably
> > worth fixing, but might be a big change to roll into this one.
> > 
> >
https://codereview.chromium.org/1430813002/diff/100001/cc/output/ca_layer_ove...
> > File cc/output/ca_layer_overlay.h (right):
> > 
> >
https://codereview.chromium.org/1430813002/diff/100001/cc/output/ca_layer_ove...
> > cc/output/ca_layer_overlay.h:25: unsigned contents_resource_id;
> > On 2015/11/12 14:36:18, alexst (slow to review) wrote:
> > > I wonder if we could fork things a bit further downstream and refactor the
> > code
> > > a bit.
> > > 
> > > I made the original overlay candidate struct intentionally small and
limited
> > in
> > > scope with the expectation that we could grow it as needed by all
platforms.
> > > Things like background color and matrix transform are not out of place
there,
> > it
> > > would be nice to branch into platform code as late as possible.
> > > 
> > > It's not a major objection, I would be fine with current code, but I can't
> > shake
> > > the feeling it could stay a bit more generic in earlier stages.
> > 
> > I was going in this direction at first, but back in
> > https://codereview.chromium.org/1394403002/, we decided to do a fork at
around
> > this level.
> > 
> > The CALayer representation of an overlay is very different from the hardware
> > overlay planes (CALayers don't even have pixel rects -- they have
floating-point
> > size and then a 3D transform matrix), so merging the two would be fairly
> > difficult. I also wanted to reuse OverlayCandidate::FromDrawQuad, but there
> > ended up being very little to share.
> > 
> > That said, when we add Wayland and/or DirectCompositing support, we may
finally
> > see a way to merge these.
> 
> Fair enough. This looks good, but let me take another pass to make sure I
didn't miss any details.

Having spent some time thinking about how to allow this type of output from
chrome (calayers, wayland sub-surface hierarchy, direct compositing, etc.) I'm
convinced that the overlay mechanism is not the right long term approach. The
cc::Renderer interface seems like a better fit for implementing these types of
output and the overlay system is better left as a clean implementation targeted
for real hardware overlays. Using the overlay system short term is fine with me
as long as the design is kept in a state that makes sense for real overlays.
Background color and transforms might be a good fit for ScheduleOverlayPlane but
extending it to support everything we might need for calayers is probably not.
Hence, the ScheduleCALayer alternative as that keeps ScheduleOverlayPlane clean
and it becomes easy to rip it out when no longer needed.

[ccameron, 2015-11-14 00:12:55]

Is this good to go?

[ccameron, 2015-11-16 22:43:28]

On 2015/11/14 00:12:55, ccameron wrote:
> Is this good to go?

Ping on this.

[reveman, 2015-11-16 23:18:53]

lgtm % alexst's overlay owner review

[alexst (slow to review), 2015-11-17 13:21:17]

lgtm, the motivation for splitting up makes sense.

[ccameron, 2015-11-17 19:35:38]

Thanks!

[ccameron, 2015-11-17 19:35:44]

The CQ bit was checked by ccameron@chromium.org

[commit-bot: I haz the power, 2015-11-17 19:36:01]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1430813002/100001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1430813002/100001

[ccameron, 2015-11-17 19:38:43]

The CQ bit was unchecked by ccameron@chromium.org

[commit-bot: I haz the power, 2015-11-17 19:39:43]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-17 19:39:44]

Try jobs failed on following builders:
  ios_dbg_simulator_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_dbg_simulator...)
  ios_rel_device_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device_ni...)
  mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_gn_rel on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_gn_r...)
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[ccameron, 2015-11-17 20:45:39]

The CQ bit was checked by ccameron@chromium.org

[ccameron, 2015-11-17 20:45:39]

The patchset sent to the CQ was uploaded after l-g-t-m from alexst@chromium.org,
reveman@chromium.org
Link to the patchset: https://codereview.chromium.org/1430813002/#ps120001
(title: "Rebase")

[commit-bot: I haz the power, 2015-11-17 20:46:15]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1430813002/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1430813002/120001

[commit-bot: I haz the power, 2015-11-17 21:23:03]

Committed patchset #7 (id:120001)

[commit-bot: I haz the power, 2015-11-17 21:24:00]

Patchset 7 (id:??) landed as
https://crrev.com/35db390a4fe9bef22036e69683cdbcce0c6f9a49
Cr-Commit-Position: refs/heads/master@{#360163}