Track transform animation content readiness on TransformNode.

cc/trees/transform_node.h

Index: cc/trees/transform_node.h
diff --git a/cc/trees/transform_node.h b/cc/trees/transform_node.h
index 2abfb1cc00480b7eb14ed6dab868d15a165a4096..2cdfbbe1ae2c5607d0b4eea74af16e45720dc142 100644
--- a/cc/trees/transform_node.h
+++ b/cc/trees/transform_node.h
@@ -123,6 +123,10 @@ struct CC_EXPORT TransformNode {
   // We need to track changes to to_screen transform to compute the damage rect.
   bool transform_changed : 1;
 
+  // Whether all tiles for the animation's content have been ready
+  // since the transform last animated. Only relevant when animated.
+  bool ready_since_animation : 1;

[wkorman, 2017/05/20 01:31:28]

Is there a reason we can't/shouldn't do this on the transform node rather than
the layer?

[pdr., 2017/05/22 17:03:34]

Tiles sort of feel like a Layer concept more than a property tree concept. We
will still have both Layers and property nodes in SPV2; could this be put on
layer instead while still getting the benefits of this patch?

[wkorman, 2017/05/22 17:18:25]

Well, it's already on Layer (well, LayerImpl) today. Really this patch is just
moving it to TransformNode.

In order to remove references to element_id on Layer instances we have to either
move this to TransformNode or explore some alternate rework of the code path
that ends up calling LayerTreeHostImpl::ElementIsAnimatingChanged where we use
LayerByElementId today. Am definitely open to alternate approaches.

The particular thing being tracked is related to transform animations (and
specifically translates). In general I think, given that, it can make sense to
track on transform node directly. There are some animation specific methods on
LayerImpl, and this one field at ToT, but I would not be surprised if we end up
removing all of these as part of http://crbug.com/709137.

[enne (OOO), 2017/05/22 18:51:59]

Sorry, but I agree strongly with pdr here.  Tiles and quads are a Layer concept.
 Transform nodes should know nothing about them.  Many layers can share the same
transform node.  It looks like one layer being ready here would clobber the
value for all the other layers that share the same node, which seems incorrect.

[wkorman, 2017/05/22 18:55:52]

That's cool, I am happy to rework it. How do you feel about jaydasika@ comment
on this patch re: proposed rework which would still have a field on the node but
also have one on layer? That sounds workable but would still, for some
definition thereof, leak the concept of tile/quad content into the node. Because
otherwise why would we have that field on the node.

+
   // TODO(vollick): will be moved when accelerated effects are implemented.
   float post_local_scale_factor;