[cc] Add SkBlendMode::kDstIn support to cc::Layer

[cc] Add SkBlendMode::kDstIn support to cc::Layer

This CL adds SkBlendMode::kDstIn support to cc::Layer. kDstIn is useful for
applying an alpha mask to a group. There is an ongoing plan to use kDstIn to
replace mask-layer-based CSS mask implementation.

The SPv2 implementation of CSS mask uses this alternative approach:
https://codereview.chromium.org/2641173008/
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2659023003
Cr-Commit-Position: refs/heads/master@{#447153}
Committed: https://chromium.googlesource.com/chromium/src/+/7bc8fc1007007ece8eaa4137967c3162bad4db08

[trchen, 2017-01-28 02:43:17]

Description was changed from

==========
[cc] Add SkBlendMode::kDstIn support to cc::Layer

This CL adds SkBlendMode::kDstIn support to cc::Layer. kDstIn is useful for
applying an alpha mask to a group. There is an ongoing plan to use kDstIn to
replace mask-layer-based CSS mask implementation.

The SPv2 implementation of CSS mask uses this alternative approach:
https://codereview.chromium.org/2641173008/
==========

to

==========
[cc] Add SkBlendMode::kDstIn support to cc::Layer

This CL adds SkBlendMode::kDstIn support to cc::Layer. kDstIn is useful for
applying an alpha mask to a group. There is an ongoing plan to use kDstIn to
replace mask-layer-based CSS mask implementation.

The SPv2 implementation of CSS mask uses this alternative approach:
https://codereview.chromium.org/2641173008/
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
==========

[trchen, 2017-01-28 02:44:13]

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

[trchen, 2017-01-28 02:44:18]

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

[commit-bot: I haz the power, 2017-01-28 02:44:38]

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-01-28 03:35:30]

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

[commit-bot: I haz the power, 2017-01-28 03:35:30]

Dry run: This issue passed the CQ dry run.

[enne (OOO), 2017-01-30 18:56:54]

https://codereview.chromium.org/2659023003/diff/1/cc/layers/render_surface_im...
File cc/layers/render_surface_impl.cc (right):

https://codereview.chromium.org/2659023003/diff/1/cc/layers/render_surface_im...
cc/layers/render_surface_impl.cc:406: // The software renderer applies mask
layer and blending in the wrong
Can you explain this restriction a little bit more? I'm not sure I understand
what's going on, or why it only applies to the software renderer.

[trchen, 2017-01-30 23:07:06]

https://codereview.chromium.org/2659023003/diff/1/cc/layers/render_surface_im...
File cc/layers/render_surface_impl.cc (right):

https://codereview.chromium.org/2659023003/diff/1/cc/layers/render_surface_im...
cc/layers/render_surface_impl.cc:406: // The software renderer applies mask
layer and blending in the wrong
On 2017/01/30 18:56:54, enne wrote:
> Can you explain this restriction a little bit more? I'm not sure I understand
> what's going on, or why it only applies to the software renderer.

Let's make a simple example. Assuming we are drawing a surface with kDstIn onto
a target, with the following pre-multiplied pixel values:

destination(existing pixel on the target surface): {r=0.8, g=0, b=0, a=0.8}
source(pixel on the current layer): {r=0, g=0.5, b=0, a=0.5}
mask: {rgb=_, a=0.2}

What should be the result pixel value? If we followed the CSS order, the source
should be masked first, resulting in a source value of {0, 0.1, 0, 0.1}, then
drawn into destination with kDstIn: {0.08, 0, 0, 0.08}. This is also what GL
renderer implements.

The software renderer implements it differently. The mask is processed in the
rasterizer phase, effectively applied after the blending phase. So the source
and destination is first blended with kDstIn to get {0.4, 0, 0, 0.4}, then the
value gets interpolated with the destination in 0.2:0.8 ratio: {0.8, 0, 0, 0.8}
* 0.8 + {0.4, 0, 0, 0.4} * 0.2 = {0.72,0, 0, 0.72}.

This is okay for other SkBlendMode we support because they are true blend mode
not affected by alpha value, where kDstIn is in fact a compositing mode thus
doesn't commute with other alpha operations.

It is not too difficult to fix the software renderer, by making masks a
SkComposeShader. However the performance implication needs to be experimented
and is beyond the scope of this CL.

[enne (OOO), 2017-01-30 23:51:21]

Ok, thanks! I never knew that the order of operations there were different.

Am I right in understanding that it's just inconsistent to use this blend mode
on a layer that has a mask in software mode? And in the future you're planning
on having either a mask layer *or* using this blend mode, so it shouldn't ever
happen in practice?

[trchen, 2017-01-30 23:55:45]

On 2017/01/30 23:51:21, enne wrote:
> Ok, thanks! I never knew that the order of operations there were different.
> 
> Am I right in understanding that it's just inconsistent to use this blend mode
> on a layer that has a mask in software mode? And in the future you're planning
> on having either a mask layer *or* using this blend mode, so it shouldn't ever
> happen in practice?

Exactly. The DCHECK is there to catch inadvertent use of this configuration.
(And people will know where to fix if they do want to support it.)

[enne (OOO), 2017-01-30 23:56:51]

lgtm

[trchen, 2017-01-31 00:09:51]

The CQ bit was checked by trchen@chromium.org

[commit-bot: I haz the power, 2017-01-31 00:10:31]

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-01-31 01:26:12]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1485821391648800, "parent_rev":
"507c8a3ed5bc7686ac0e7d9a6b9db0d0d413a63b", "commit_rev":
"7bc8fc1007007ece8eaa4137967c3162bad4db08"}

[commit-bot: I haz the power, 2017-01-31 01:26:46]

Description was changed from

==========
[cc] Add SkBlendMode::kDstIn support to cc::Layer

This CL adds SkBlendMode::kDstIn support to cc::Layer. kDstIn is useful for
applying an alpha mask to a group. There is an ongoing plan to use kDstIn to
replace mask-layer-based CSS mask implementation.

The SPv2 implementation of CSS mask uses this alternative approach:
https://codereview.chromium.org/2641173008/
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
==========

to

==========
[cc] Add SkBlendMode::kDstIn support to cc::Layer

This CL adds SkBlendMode::kDstIn support to cc::Layer. kDstIn is useful for
applying an alpha mask to a group. There is an ongoing plan to use kDstIn to
replace mask-layer-based CSS mask implementation.

The SPv2 implementation of CSS mask uses this alternative approach:
https://codereview.chromium.org/2641173008/
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2659023003
Cr-Commit-Position: refs/heads/master@{#447153}
Committed:
https://chromium.googlesource.com/chromium/src/+/7bc8fc1007007ece8eaa4137967c...
==========

[commit-bot: I haz the power, 2017-01-31 01:26:47]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/chromium/src/+/7bc8fc1007007ece8eaa4137967c...