Add DCLayerOverlayProcessor and supporting DCLayer structures.

Add DCLayerOverlayProcessor and supporting DCLayer structures.

DirectComposition layers are more flexible than normal hardware overlays
- for example they can have clip rects, be arbitrarily transformed, and
soon will have other capabilities like stacking contexts. So it makes
sense to transmit them to the GPU process using a new
glScheduleDCLayerCHROMIUM command.

The gpu command buffer code is mostly a copy and paste of the CALayer
code. The main difference for now is that it has a z order instead
of a sorting context, but they'll diverge more over time.

We can't DCLayers the same exact way as we currently use CALayers
because tile quads aren't accessible as DirectComposition surfaces so
complete RenderPasses can't be converted to use DCLayers. So we need to
create a new DCLayerOverlayProcessor that behaves somewhat similarly to
the regular OverlayProcessor.

This processor supports both promoting a single on top quad to an
overlay, as well as promoting other video quads to be underlays.

BUG=678800
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2736643004
Cr-Commit-Position: refs/heads/master@{#456512}
Committed: https://chromium.googlesource.com/chromium/src/+/80ceeee5bc83abc038e4e8cc4e0e8d0fbc710576

[jbauman, 2017-03-07 04:54:59]

Description was changed from

==========
Add DCLayerOverlayProcessor

DirectComposition layers are more flexible than normal hardware overlays
- for example they can have clip rects, be arbitrarily transformed, and
soon will have other capabilities like stacking contexts. So it makes
sense to transmit them to the GPU process using
glScheduleCALayerCHROMIUM.

However we can't use them the same exact way as we currently use
CALayers because tile quads aren't accessible as DirectComposition
surfaces so complete RenderPasses can't be converted to use CALayers. So
we need to create a new DCLayerOverlayProcessor than can create CALayer
verlays just for the video draw quads.

This processor supports both promoting a single on top quad to an
overlay, as well as promoting other video quads to be underlays.

BUG=678800
==========

to

==========
Add DCLayerOverlayProcessor

DirectComposition layers are more flexible than normal hardware overlays
- for example they can have clip rects, be arbitrarily transformed, and
soon will have other capabilities like stacking contexts. So it makes
sense to transmit them to the GPU process using
glScheduleCALayerCHROMIUM.

However we can't use them the same exact way as we currently use
CALayers because tile quads aren't accessible as DirectComposition
surfaces so complete RenderPasses can't be converted to use CALayers. So
we need to create a new DCLayerOverlayProcessor than can create CALayer
verlays just for the video draw quads.

This processor supports both promoting a single on top quad to an
overlay, as well as promoting other video quads to be underlays.

BUG=678800
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
==========

[jbauman, 2017-03-07 04:55:05]

The CQ bit was checked by jbauman@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-07 04:55:36]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-07 07:55:36]

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

[commit-bot: I haz the power, 2017-03-07 07:55:37]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[jbauman, 2017-03-07 22:56:35]

jbauman@chromium.org changed reviewers:
+ ccameron@chromium.org

[ccameron, 2017-03-08 01:02:39]

I'd prefer not to reuse the CALayerOverlay structure For expediency (if we're
iterating on designs), I'm fine with sharing it. But long term, I'd rather they
branch.

lgtm otherwise

https://codereview.chromium.org/2736643004/diff/1/cc/output/overlay_processor.cc
File cc/output/overlay_processor.cc (right):

https://codereview.chromium.org/2736643004/diff/1/cc/output/overlay_processor...
cc/output/overlay_processor.cc:147: ca_layer_overlays, damage_rect)) {
Would it be possible to share UpdateDamageRect instead of tracking damage inside
the DC processor? That logic always ends up being hairy, so I'd suggest keeping
it shared if possible.

[jbauman, 2017-03-08 23:13:01]

Description was changed from

==========
Add DCLayerOverlayProcessor

DirectComposition layers are more flexible than normal hardware overlays
- for example they can have clip rects, be arbitrarily transformed, and
soon will have other capabilities like stacking contexts. So it makes
sense to transmit them to the GPU process using
glScheduleCALayerCHROMIUM.

However we can't use them the same exact way as we currently use
CALayers because tile quads aren't accessible as DirectComposition
surfaces so complete RenderPasses can't be converted to use CALayers. So
we need to create a new DCLayerOverlayProcessor than can create CALayer
verlays just for the video draw quads.

This processor supports both promoting a single on top quad to an
overlay, as well as promoting other video quads to be underlays.

BUG=678800
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
==========

to

==========
Add DCLayerOverlayProcessor

DirectComposition layers are more flexible than normal hardware overlays
- for example they can have clip rects, be arbitrarily transformed, and
soon will have other capabilities like stacking contexts. So it makes
sense to transmit them to the GPU process using
glScheduleCALayerCHROMIUM.

However we can't use them the same exact way as we currently use
CALayers because tile quads aren't accessible as DirectComposition
surfaces so complete RenderPasses can't be converted to use CALayers. So
we need to create a new DCLayerOverlayProcessor than can create CALayer
verlays just for the video draw quads.

This processor supports both promoting a single on top quad to an
overlay, as well as promoting other video quads to be underlays.

BUG=678800
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[jbauman, 2017-03-08 23:13:07]

The CQ bit was checked by jbauman@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-08 23:13:53]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[jbauman, 2017-03-09 00:00:53]

Description was changed from

==========
Add DCLayerOverlayProcessor

DirectComposition layers are more flexible than normal hardware overlays
- for example they can have clip rects, be arbitrarily transformed, and
soon will have other capabilities like stacking contexts. So it makes
sense to transmit them to the GPU process using
glScheduleCALayerCHROMIUM.

However we can't use them the same exact way as we currently use
CALayers because tile quads aren't accessible as DirectComposition
surfaces so complete RenderPasses can't be converted to use CALayers. So
we need to create a new DCLayerOverlayProcessor than can create CALayer
verlays just for the video draw quads.

This processor supports both promoting a single on top quad to an
overlay, as well as promoting other video quads to be underlays.

BUG=678800
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
Add DCLayerOverlayProcessor and supporting DCLayer structures.

DirectComposition layers are more flexible than normal hardware overlays
- for example they can have clip rects, be arbitrarily transformed, and
soon will have other capabilities like stacking contexts. So it makes
sense to transmit them to the GPU process using a new
glScheduleDCLayerCHROMIUM command.

The gpu command buffer code is mostly a copy and paste of the CALayer
code. The main difference for now is that it has a z order instead
of a sorting context, but they'll diverge more over time.

We can't DCLayers the same exact way as we currently use CALayers
because tile quads aren't accessible as DirectComposition surfaces so
complete RenderPasses can't be converted to use DCLayers. So we need to
create a new DCLayerOverlayProcessor that behaves somewhat similarly to
the regular OverlayProcessor.

This processor supports both promoting a single on top quad to an
overlay, as well as promoting other video quads to be underlays.

BUG=678800
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[jbauman, 2017-03-09 00:59:28]

Ok, in this version splitting out everything DCLayer related from the CALayer
stuff, including the gl commands, DCLayerOverlay, etc.

On 2017/03/08 01:02:39, ccameron wrote:
> I'd prefer not to reuse the CALayerOverlay structure For expediency (if we're
> iterating on designs), I'm fine with sharing it. But long term, I'd rather
they
> branch.
> 
> lgtm otherwise
> 
>
https://codereview.chromium.org/2736643004/diff/1/cc/output/overlay_processor.cc
> File cc/output/overlay_processor.cc (right):
> 
>
https://codereview.chromium.org/2736643004/diff/1/cc/output/overlay_processor...
> cc/output/overlay_processor.cc:147: ca_layer_overlays, damage_rect)) {
> Would it be possible to share UpdateDamageRect instead of tracking damage
inside
> the DC processor? That logic always ends up being hairy, so I'd suggest
keeping
> it shared if possible.

Unfortunately UpdateDamageRect depends on OverlayCandidates to do anything. The
semantics are even different between OverlayCandidates and the DCLayer stuff
with regard to transforms, clipping rect existence, etc., so it'd be hard to
unify.

[commit-bot: I haz the power, 2017-03-09 01:41:38]

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

[commit-bot: I haz the power, 2017-03-09 01:41:39]

Dry run: This issue passed the CQ dry run.

[jbauman, 2017-03-13 19:45:43]

The CQ bit was checked by jbauman@chromium.org

[jbauman, 2017-03-13 19:45:43]

The patchset sent to the CQ was uploaded after l-g-t-m from
ccameron@chromium.org
Link to the patchset: https://codereview.chromium.org/2736643004/#ps20001
(title: "split CALayerOverlay into DCLayerOverlay")

[commit-bot: I haz the power, 2017-03-13 19:46:32]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-13 21:27:40]

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

[commit-bot: I haz the power, 2017-03-13 21:27:41]

Try jobs failed on following builders:
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[jbauman, 2017-03-13 21:46:36]

The CQ bit was checked by jbauman@chromium.org

[commit-bot: I haz the power, 2017-03-13 21:47:37]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-13 22:44:01]

CQ is committing da patch.

Bot data: {"patchset_id": 20001, "attempt_start_ts": 1489441596397230,
"parent_rev": "e69df7ab2555ce8874972c419b13add8e0ec0c32", "commit_rev":
"80ceeee5bc83abc038e4e8cc4e0e8d0fbc710576"}

[commit-bot: I haz the power, 2017-03-13 22:44:44]

Description was changed from

==========
Add DCLayerOverlayProcessor and supporting DCLayer structures.

DirectComposition layers are more flexible than normal hardware overlays
- for example they can have clip rects, be arbitrarily transformed, and
soon will have other capabilities like stacking contexts. So it makes
sense to transmit them to the GPU process using a new
glScheduleDCLayerCHROMIUM command.

The gpu command buffer code is mostly a copy and paste of the CALayer
code. The main difference for now is that it has a z order instead
of a sorting context, but they'll diverge more over time.

We can't DCLayers the same exact way as we currently use CALayers
because tile quads aren't accessible as DirectComposition surfaces so
complete RenderPasses can't be converted to use DCLayers. So we need to
create a new DCLayerOverlayProcessor that behaves somewhat similarly to
the regular OverlayProcessor.

This processor supports both promoting a single on top quad to an
overlay, as well as promoting other video quads to be underlays.

BUG=678800
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
Add DCLayerOverlayProcessor and supporting DCLayer structures.

DirectComposition layers are more flexible than normal hardware overlays
- for example they can have clip rects, be arbitrarily transformed, and
soon will have other capabilities like stacking contexts. So it makes
sense to transmit them to the GPU process using a new
glScheduleDCLayerCHROMIUM command.

The gpu command buffer code is mostly a copy and paste of the CALayer
code. The main difference for now is that it has a z order instead
of a sorting context, but they'll diverge more over time.

We can't DCLayers the same exact way as we currently use CALayers
because tile quads aren't accessible as DirectComposition surfaces so
complete RenderPasses can't be converted to use DCLayers. So we need to
create a new DCLayerOverlayProcessor that behaves somewhat similarly to
the regular OverlayProcessor.

This processor supports both promoting a single on top quad to an
overlay, as well as promoting other video quads to be underlays.

BUG=678800
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2736643004
Cr-Commit-Position: refs/heads/master@{#456512}
Committed:
https://chromium.googlesource.com/chromium/src/+/80ceeee5bc83abc038e4e8cc4e0e...
==========

[commit-bot: I haz the power, 2017-03-13 22:44:45]

Committed patchset #2 (id:20001) as
https://chromium.googlesource.com/chromium/src/+/80ceeee5bc83abc038e4e8cc4e0e...