FOR DISCUSSION: Implement indirect compositing reasons for effect nodes.

Implement indirect compositing reasons for effect nodes.

The reasons can be:

1. One or more PaintChunks under an effect has a direct compositing reason.
2. PaintChunks under an effect end up in more than one cc::Layer.

These are required in order to make sure that all affects are applied atomically
(grouping).

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

[chrishtr, 2017-03-01 17:13:13]

Description was changed from

==========
none


none


none

BUG=
==========

to

==========
none


none


none

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
==========

[chrishtr, 2017-03-01 17:18:15]

Description was changed from

==========
none


none


none

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
==========

to

==========
Implement indirect compositing reasons for effect nodes.

The reasons can be:

1. One or more PaintChunks under an effect has a direct compositing reason.
2. PaintChunks under an effect end up in more than one cc::Layer.

These are required in order to make sure that all affects are applied atomically
(grouping).

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
==========

[chrishtr, 2017-03-01 18:19:44]

chrishtr@chromium.org changed reviewers:
+ pdr@chromium.org, trchen@chromium.org

[chrishtr, 2017-03-01 18:19:44]

Alternate CL to https://codereview.chromium.org/2714673002 as discussed.

I ran it on fast/backgrounds/opacity-on-document-element.html and it failed, but
not
sure why. It did promote an effect to composited on the second pass. Also, I ran
the same test with https://codereview.chromium.org/2714673002 and it also
failed.
Let's debug together later today.

[trchen, 2017-03-01 23:02:59]

I only spotted 2 bugs that are very local. Still can't convince myself the
algorithm will be correct 100% of the time though.

https://codereview.chromium.org/2729613002/diff/20001/third_party/WebKit/Sour...
File
third_party/WebKit/Source/platform/graphics/compositing/PaintArtifactCompositor.cpp
(right):

https://codereview.chromium.org/2729613002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/graphics/compositing/PaintArtifactCompositor.cpp:603:
compositedEffectNodes->end()) {
I think this line will over-composite many of the chunks.

Chunk only needs compositing if the state switch across a compositing boundary,
but is okay to have a node that is right on the boundary. This should fix it:

if (currentState->innerMostNode() == Effect &&
    compositedEffectNodes &&
    compositedEffectNodes->find(currentState->effect()) !=
        compositedEffectNodes->end()) {

https://codereview.chromium.org/2729613002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/graphics/compositing/PaintArtifactCompositor.cpp:730:
.hasDirectCompositingReasons()) {
propertyTreeState.hasDirectCompositingReasons() only look at the innermost node.
There can be compositing reason in the chain between chunk state and the
effect's input space. For example:

<div style="opacity:0.5;">
  <div style="will-change:transform;">
    <div style="overflow:hidden;">Chunk</div>
  </div>
</div>

We also want to check the output space of each effect in the chain, for example:

<div style="opacity:0.5">
  <div style="will-change:transform;">
    <div style="overflow:scroll">
      <div style="opacity:0.5">Chunk</div>
    </div>
  </div>
</div>

[chrishtr, 2017-03-09 01:31:03]

FYI I did find a bug in this patch: consider paint chunks A, B, C, D.

A and B are in effect E1. C and D are in effect E2. A overlaps D.

The algorithm as written in this CL will detect that E1 should be composited in
the first
pass. In the second pass, C will be decomposited into the root layer, but D must
be composited
because it overlaps A. This results in incorrect output because E2 would end up
contributing
to two cc::Layers.