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

cc/layers/render_surface_impl.cc

Index: cc/layers/render_surface_impl.cc
diff --git a/cc/layers/render_surface_impl.cc b/cc/layers/render_surface_impl.cc
index 1265e4f0ea0effe7cb5cd413554ba73b9b962c29..d43f72396a12ef37f3c8d5a76dd987a7bf0eef68 100644
--- a/cc/layers/render_surface_impl.cc
+++ b/cc/layers/render_surface_impl.cc
@@ -403,6 +403,12 @@ void RenderSurfaceImpl::AppendQuads(RenderPass* render_pass,
   LayerImpl* mask_layer = MaskLayer();
   if (mask_layer && mask_layer->DrawsContent() &&
       !mask_layer->bounds().IsEmpty()) {
+    // The software renderer applies mask layer and blending in the wrong

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

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]

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.

+    // order but kDstIn doesn't commute with masking. It is okay to not
+    // support this configuration because kDstIn was introduced to replace
+    // mask layers.
+    DCHECK(BlendMode() != SkBlendMode::kDstIn)
+        << "kDstIn blend mode with mask layer is unsupported.";
     mask_layer->GetContentsResourceId(&mask_resource_id, &mask_texture_size);
     gfx::SizeF unclipped_mask_target_size = gfx::ScaleSize(
         gfx::SizeF(OwningEffectNode()->unscaled_mask_target_size),