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

cc/layers/render_surface_impl.cc

 // Copyright 2011 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "cc/layers/render_surface_impl.h"
 
 #include <stddef.h>
 
 #include <algorithm>
 
@@ skipping 385 matching lines @@
   }
 
   ResourceId mask_resource_id = 0;
   gfx::Size mask_texture_size;
   gfx::Vector2dF mask_uv_scale;
   gfx::Vector2dF surface_contents_scale =
       OwningEffectNode()->surface_contents_scale;
   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),
         surface_contents_scale.x(), surface_contents_scale.y());
     mask_uv_scale = gfx::Vector2dF(1.0f / unclipped_mask_target_size.width(),
                                    1.0f / unclipped_mask_target_size.height());
   }
 
   RenderPassDrawQuad* quad =
       render_pass->CreateAndAppendDrawQuad<RenderPassDrawQuad>();
   quad->SetNew(shared_quad_state, content_rect(), visible_layer_rect,
                GetRenderPassId(), mask_resource_id, mask_uv_scale,
                mask_texture_size, surface_contents_scale, FiltersOrigin());
 }
 
 }  // namespace cc