Track transform animation content readiness on TransformNode.

cc/trees/transform_node.h

 // Copyright 2016 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.
 
 #ifndef CC_TREES_TRANSFORM_NODE_H_
 #define CC_TREES_TRANSFORM_NODE_H_
 
 #include "cc/cc_export.h"
 #include "ui/gfx/geometry/point_f.h"
 #include "ui/gfx/geometry/scroll_offset.h"
@@ skipping 105 matching lines @@
 
   // Layer scale factor is used as a fallback when we either cannot adjust
   // raster scale or if the raster scale cannot be extracted from the screen
   // space transform. For layers in the subtree of the page scale layer, the
   // layer scale factor should include the page scale factor.
   bool in_subtree_of_page_scale_layer : 1;
 
   // 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;
 
   // TODO(vollick): will be moved when accelerated effects are implemented.
   gfx::ScrollOffset scroll_offset;
 
   // This value stores the snapped amount whenever we snap. If the snap is due
   // to a scroll, we need it to calculate fixed-pos elements adjustment, even
   // otherwise we may need it to undo the snapping next frame.
   gfx::Vector2dF snap_amount;
@@ skipping 27 matching lines @@
   gfx::Transform to_screen;
 
   bool is_showing_backface : 1;
 
   bool operator==(const TransformCachedNodeData& other) const;
 };
 
 }  // namespace cc
 
 #endif  // CC_TREES_TRANSFORM_NODE_H_