mix-blend-mode implementation for accelerated layers

cc/trees/layer_tree_host_common.cc

Index: cc/trees/layer_tree_host_common.cc
diff --git a/cc/trees/layer_tree_host_common.cc b/cc/trees/layer_tree_host_common.cc
index b8436756fc4762df4194493b3d602e274a8d1ab3..49f86b990cc980cd4d189d23790db776c74eb77b 100644
--- a/cc/trees/layer_tree_host_common.cc
+++ b/cc/trees/layer_tree_host_common.cc
@@ -576,6 +576,24 @@ static bool SubtreeShouldRenderToSeparateSurface(
     return true;
   }
 
+  // If the layer has blending.
+  if (layer->has_blend_mode()) {

[shawnsingh, 2013/09/25 05:33:53]

Can we support blend modes for layers when possible, instead of needing to
create a surface?  Ideally we should add "use num_descendants_that_draw_content
> 0" as an additional condition here.  I would expect it may be a common case
that only one leaf node composited layer has a blend mode with no descendants,
and in that case we wouldn't need to create a render surface for it.

Will this greatly affect how the blend modes is actually implemented in the
gl_renderer code?

[rosca, 2013/09/25 18:00:00]

This is one of the optimizations I was thinking of. I added a comment in here to
make things clear.
Now blending code in gl_renderer is ready only for RenderPassQuad. The same idea
should work for other quad types and this has to be implemented.
Creating surfaces for each blending layer and their stacking contexts makes
mix-blend-mode work well with this patch. As the css property is under the
experimental runtime flag, I would prefer to move forward this way first and add
improvements afterwards. What do you think of this?

+      TRACE_EVENT_INSTANT0(
+          "cc",
+          "LayerTreeHostCommon::SubtreeShouldRenderToSeparateSurface blending",
+          TRACE_EVENT_SCOPE_THREAD);
+      return true;
+  }
+
+  // If the layer has isolation.
+  if (layer->is_root_for_isolated_group()) {

[enne (OOO), 2013/09/24 18:05:48]

Whoa there.  According to
http://dev.w3.org/fxtf/compositing-1/#csscompositingrules_CSS, an isolated group
is a stacking context.  I assume that you're not going to create a separate
render surface for every stacking context, right? Is this only necessary when
layer->has_blend_mode()?

On a smaller note, Layer::SetForceRenderSurface already does what you're looking
for, so please use that.

[rosca, 2013/09/24 21:22:47]

We create separate rendering surfaces only for stacking contexts having
mix-blend-mode layer descendants. This will force blending descendants to blend
with underlying content, limited to the *current* stacking context. 
I've been thinking of some optimizations in the compositor to ensure group
isolation, cases when we might not need a separate rendering surface to isolate
a group (e.g. when the root is fully opaque and its descendents don't overflow),
this is why I chose to use a new property for isolated groups. For what I have
so far, it would be enough to use SetForceRenderSurface. 

[shawnsingh, 2013/09/25 05:33:53]

Enne@ - I disagree about using setForceRenderSurface().  Why should we require
this particular feature to use setForceRenderSurface() while every other reason
has a legitimate condition in this helper function?   The whole purpose of this
helper function is to make an explicit and centralized location to maintain all
the various reasons that we would create a surface.  I feel that
setForceRenderSurface() should remain a debugging/testing tool, and not be used
as a way to bypass putting conditions directly in this function.

[enne (OOO), 2013/09/26 16:25:13]

I think there's sort of two approaches you can take here.  One is to make the
compositor not be tightly coupled to Blink features, and have Blink do the
translation from its needs to existing already exposed compositor features,
reusing them where it can.  That's what I was trying to suggest above.  This
keeps the compositor more dumb and pushes complication out to the embedder.

I could buy the argument that maybe Blink shouldn't have to think about render
surfaces, so maybe we should expose blend mode semantics.

One improvement to this code would be to have the pre-recursion count whether a
given layer has mixed blend mode descendants and only create surfaces for those
cases rather than always creating one for isolated groups.

[rosca, 2013/09/27 10:39:06]

I added a TODO comment with this improvement in the fallowing patch. Thanks.

[enne (OOO), 2013/09/27 17:42:33]

Can you file a bug, assign it to yourself, and reference it in the comment?

[rosca, 2013/09/30 17:28:36]

Here is the bug: http://crbug.com/301738. Unfortunately I cannot assign it, I
don't have the rights. Can you assign it to me?

+    TRACE_EVENT_INSTANT0(
+        "cc",
+        "LayerTreeHostCommon::SubtreeShouldRenderToSeparateSurface isolation",
+        TRACE_EVENT_SCOPE_THREAD);
+    return true;
+  }
+
   // If the layer clips its descendants but it is not axis-aligned with respect
   // to its parent.
   bool layer_clips_external_content =
@@ -1514,6 +1532,8 @@ static void CalculateDrawPropertiesInternal(
     layer_draw_properties.screen_space_opacity_is_animating =
         animating_opacity_to_screen;
 
+    render_surface->SetHasBlendMode(layer->has_blend_mode());

[shawnsingh, 2013/09/25 05:33:53]

FYI, if we do add support for blend modes on layers (as opposed to only for
render surfaces), then this line of code will be dangerous.   We would need to
distinguish between (1) a layer that has its own surface and gives the
blend-mode to the surface, versus (2) a layer that has a blend mode and draws
into a non-blend-mode surface.

[rosca, 2013/09/25 18:00:00]

I removed the has_blend_mode property from RenderSurface. It will ask
render_surface->owning_layer for the blend_mode property.

+
     render_surface->SetTargetSurfaceTransformsAreAnimating(
         animating_transform_to_target);
     render_surface->SetScreenSpaceTransformsAreAnimating(