Reland: Correctly handle damage involving filters in SurfaceAggregator

Reland: Correctly handle damage involving filters in SurfaceAggregator

There are two main issues with the handling of damage of contents
affected by RenderPassDrawQuad filters:
1) Damage of a small part of a source Surface can affect a large part
of the destination and
2) To draw damage on the destination, an unexpectedly large portion
of the source must be used.

To deal with these, the SurfaceAggregator must keep track of all output
render passes affected by filters. Any Surface in an affected RenderPass
will cause its parent Surface to be completely damaged (handling #1
above).

To handle #2, affected RenderPasses will have their damage rects set to
contain the entire output_rect. Then DirectRenderer can use that damage
rect to determine what to draw. In the case that overlays are used the
root damage rect can temporarily be expanded for the frame, so in that
case the entire child renderpass needs to be drawn.

CopyRequests can also cause areas outside the damage rect to be read, so
any RenderPass inside a CopyRequest (directly or indirectly) will have
its damage rect set to the output rect.

This system is very pessimistic about what should be drawn, but in
general it shouldn't affect that many cases and should always be
correct.

BUG=602941
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/fe19524b2c646dc6b7b8b4849e9139216805c0a7
Cr-Commit-Position: refs/heads/master@{#393084}

[jbauman, 2016-05-10 22:56:31]

Description was changed from

==========
fix some output


Revert "Revert of Correctly handle damage involving filters in SurfaceAggregator
(patchset #6 id:100001 of https://codereview.chromium.org/1927413002/ )"

This reverts commit fef422a0e8492b766d0713d9a6f5e3298c563081.

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

to

==========
fix some output


Revert "Revert of Correctly handle damage involving filters in SurfaceAggregator
(patchset #6 id:100001 of https://codereview.chromium.org/1927413002/ )"

This reverts commit fef422a0e8492b766d0713d9a6f5e3298c563081.

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

[jbauman, 2016-05-11 00:16:23]

Description was changed from

==========
fix some output


Revert "Revert of Correctly handle damage involving filters in SurfaceAggregator
(patchset #6 id:100001 of https://codereview.chromium.org/1927413002/ )"

This reverts commit fef422a0e8492b766d0713d9a6f5e3298c563081.

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

to

==========
Reland: Correctly handle damage involving filters in SurfaceAggregator

There are two main issues with the handling of damage of contents
affected by RenderPassDrawQuad filters:
1) Damage of a small part of a source Surface can affect a large part
of the destination and
2) To draw damage on the destination, an unexpectedly large portion
of the source must be used.

To deal with these, the SurfaceAggregator must keep track of all output
render passes affected by filters. Any Surface in an affected RenderPass
will cause its parent Surface to be completely damaged (handling #1
above).

To handle #2, affected RenderPasses will have their damage rects set to
contain the entire output_rect. Then DirectRenderer can use that damage
rect to determine what to draw. In the case that overlays are used the
root damage rect can temporarily be expanded for the frame, so in that
case the entire child renderpass needs to be drawn.

CopyRequests can also cause areas outside the damage rect to be read, so
any RenderPass inside a CopyRequest (directly or indirectly) will have
its damage rect set to the output rect.

This system is very pessimistic about what should be drawn, but in
general it shouldn't affect that many cases and should always be
correct.

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

[jbauman, 2016-05-11 00:18:25]

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

[jbauman, 2016-05-11 00:18:25]

The only difference from the previous patch is in the case where the overlay
code expanded the damage rect, which seems to happen on mac on the first frame
after it switches away from using overlays to draw.

[piman, 2016-05-11 19:07:06]

lgtm

[jbauman, 2016-05-11 20:19:07]

The CQ bit was checked by jbauman@chromium.org

[commit-bot: I haz the power, 2016-05-11 20:19:45]

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

[commit-bot: I haz the power, 2016-05-11 22:06:25]

Description was changed from

==========
Reland: Correctly handle damage involving filters in SurfaceAggregator

There are two main issues with the handling of damage of contents
affected by RenderPassDrawQuad filters:
1) Damage of a small part of a source Surface can affect a large part
of the destination and
2) To draw damage on the destination, an unexpectedly large portion
of the source must be used.

To deal with these, the SurfaceAggregator must keep track of all output
render passes affected by filters. Any Surface in an affected RenderPass
will cause its parent Surface to be completely damaged (handling #1
above).

To handle #2, affected RenderPasses will have their damage rects set to
contain the entire output_rect. Then DirectRenderer can use that damage
rect to determine what to draw. In the case that overlays are used the
root damage rect can temporarily be expanded for the frame, so in that
case the entire child renderpass needs to be drawn.

CopyRequests can also cause areas outside the damage rect to be read, so
any RenderPass inside a CopyRequest (directly or indirectly) will have
its damage rect set to the output rect.

This system is very pessimistic about what should be drawn, but in
general it shouldn't affect that many cases and should always be
correct.

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

to

==========
Reland: Correctly handle damage involving filters in SurfaceAggregator

There are two main issues with the handling of damage of contents
affected by RenderPassDrawQuad filters:
1) Damage of a small part of a source Surface can affect a large part
of the destination and
2) To draw damage on the destination, an unexpectedly large portion
of the source must be used.

To deal with these, the SurfaceAggregator must keep track of all output
render passes affected by filters. Any Surface in an affected RenderPass
will cause its parent Surface to be completely damaged (handling #1
above).

To handle #2, affected RenderPasses will have their damage rects set to
contain the entire output_rect. Then DirectRenderer can use that damage
rect to determine what to draw. In the case that overlays are used the
root damage rect can temporarily be expanded for the frame, so in that
case the entire child renderpass needs to be drawn.

CopyRequests can also cause areas outside the damage rect to be read, so
any RenderPass inside a CopyRequest (directly or indirectly) will have
its damage rect set to the output rect.

This system is very pessimistic about what should be drawn, but in
general it shouldn't affect that many cases and should always be
correct.

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

[commit-bot: I haz the power, 2016-05-11 22:06:25]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-05-11 22:07:45]

Description was changed from

==========
Reland: Correctly handle damage involving filters in SurfaceAggregator

There are two main issues with the handling of damage of contents
affected by RenderPassDrawQuad filters:
1) Damage of a small part of a source Surface can affect a large part
of the destination and
2) To draw damage on the destination, an unexpectedly large portion
of the source must be used.

To deal with these, the SurfaceAggregator must keep track of all output
render passes affected by filters. Any Surface in an affected RenderPass
will cause its parent Surface to be completely damaged (handling #1
above).

To handle #2, affected RenderPasses will have their damage rects set to
contain the entire output_rect. Then DirectRenderer can use that damage
rect to determine what to draw. In the case that overlays are used the
root damage rect can temporarily be expanded for the frame, so in that
case the entire child renderpass needs to be drawn.

CopyRequests can also cause areas outside the damage rect to be read, so
any RenderPass inside a CopyRequest (directly or indirectly) will have
its damage rect set to the output rect.

This system is very pessimistic about what should be drawn, but in
general it shouldn't affect that many cases and should always be
correct.

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

to

==========
Reland: Correctly handle damage involving filters in SurfaceAggregator

There are two main issues with the handling of damage of contents
affected by RenderPassDrawQuad filters:
1) Damage of a small part of a source Surface can affect a large part
of the destination and
2) To draw damage on the destination, an unexpectedly large portion
of the source must be used.

To deal with these, the SurfaceAggregator must keep track of all output
render passes affected by filters. Any Surface in an affected RenderPass
will cause its parent Surface to be completely damaged (handling #1
above).

To handle #2, affected RenderPasses will have their damage rects set to
contain the entire output_rect. Then DirectRenderer can use that damage
rect to determine what to draw. In the case that overlays are used the
root damage rect can temporarily be expanded for the frame, so in that
case the entire child renderpass needs to be drawn.

CopyRequests can also cause areas outside the damage rect to be read, so
any RenderPass inside a CopyRequest (directly or indirectly) will have
its damage rect set to the output rect.

This system is very pessimistic about what should be drawn, but in
general it shouldn't affect that many cases and should always be
correct.

BUG=602941
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/fe19524b2c646dc6b7b8b4849e9139216805c0a7
Cr-Commit-Position: refs/heads/master@{#393084}
==========

[commit-bot: I haz the power, 2016-05-11 22:07:46]

Patchset 1 (id:??) landed as
https://crrev.com/fe19524b2c646dc6b7b8b4849e9139216805c0a7
Cr-Commit-Position: refs/heads/master@{#393084}

[Stephen White, 2016-05-12 15:32:10]

senorblanco@chromium.org changed reviewers:
+ senorblanco@chromium.org

[Stephen White, 2016-05-12 15:32:11]

https://codereview.chromium.org/1966073002/diff/1/cc/surfaces/surface_aggrega...
File cc/surfaces/surface_aggregator.cc (right):

https://codereview.chromium.org/1966073002/diff/1/cc/surfaces/surface_aggrega...
cc/surfaces/surface_aggregator.cc:664: damage_rect = full_damage;
FYI, we could use FilterOperation::MapRect() here to get an exact mapping of the
damage rect, if we still have access to the filter operations that at this
level. However, we'll have to add the map direction as a param to MapRect, since
I think we need SkImageFilter::kReverse_MapDirection.

[jbauman, 2016-05-13 00:41:14]

On 2016/05/12 15:32:11, Stephen White wrote:
>
https://codereview.chromium.org/1966073002/diff/1/cc/surfaces/surface_aggrega...
> File cc/surfaces/surface_aggregator.cc (right):
> 
>
https://codereview.chromium.org/1966073002/diff/1/cc/surfaces/surface_aggrega...
> cc/surfaces/surface_aggregator.cc:664: damage_rect = full_damage;
> FYI, we could use FilterOperation::MapRect() here to get an exact mapping of
the
> damage rect, if we still have access to the filter operations that at this
> level. However, we'll have to add the map direction as a param to MapRect,
since
> I think we need SkImageFilter::kReverse_MapDirection.

Yeah, though we'd need to reconstruct the complete renderpass tree, including
transforms and filters at every RenderPassDrawQuad, to be able to do that. I
figure we can add that complexity if this seems like a performance issue.