cc: Simplify picture layer tiling update tile priorities.

cc/resources/tile_priority.h

Index: cc/resources/tile_priority.h
diff --git a/cc/resources/tile_priority.h b/cc/resources/tile_priority.h
index 0052e40ddce8e86129a55432cde7a33c1068f0e4..0f1a4bc5afbccff4a7033192e7b6d6450959b164 100644
--- a/cc/resources/tile_priority.h
+++ b/cc/resources/tile_priority.h
@@ -41,19 +41,25 @@ scoped_ptr<base::Value> TileResolutionAsValue(
     TileResolution resolution);
 
 struct CC_EXPORT TilePriority {
+  enum PriorityBin {
+    NOW,
+    SOON,
+    EVENTUALLY
+  };
+
   TilePriority()
       : resolution(NON_IDEAL_RESOLUTION),
         required_for_activation(false),
-        time_to_visible_in_seconds(std::numeric_limits<float>::infinity()),
-        distance_to_visible_in_pixels(std::numeric_limits<float>::infinity()) {}
+        priority_bin(EVENTUALLY),
+        distance_to_visible(std::numeric_limits<float>::infinity()) {}
 
   TilePriority(TileResolution resolution,
-               float time_to_visible_in_seconds,
-               float distance_to_visible_in_pixels)
+               PriorityBin bin,
+               float distance_to_visible)
       : resolution(resolution),
         required_for_activation(false),
-        time_to_visible_in_seconds(time_to_visible_in_seconds),
-        distance_to_visible_in_pixels(distance_to_visible_in_pixels) {}
+        priority_bin(bin),
+        distance_to_visible(distance_to_visible) {}
 
   TilePriority(const TilePriority& active, const TilePriority& pending) {
     if (active.resolution == HIGH_RESOLUTION ||
@@ -68,28 +74,25 @@ struct CC_EXPORT TilePriority {
     required_for_activation =
         active.required_for_activation || pending.required_for_activation;
 
-    time_to_visible_in_seconds =
-      std::min(active.time_to_visible_in_seconds,
-               pending.time_to_visible_in_seconds);
-    distance_to_visible_in_pixels =
-      std::min(active.distance_to_visible_in_pixels,
-               pending.distance_to_visible_in_pixels);
+    if (active.priority_bin < pending.priority_bin) {
+      priority_bin = active.priority_bin;
+      distance_to_visible = active.distance_to_visible;
+    } else if (active.priority_bin > pending.priority_bin) {
+      priority_bin = pending.priority_bin;
+      distance_to_visible = pending.distance_to_visible;
+    } else {
+      priority_bin = active.priority_bin;
+      distance_to_visible =
+          std::min(active.distance_to_visible, pending.distance_to_visible);
+    }
   }
 
   scoped_ptr<base::Value> AsValue() const;
 
-  // Calculate the time for the |current_bounds| to intersect with the
-  // |target_bounds| given its previous location and time delta.
-  // This function should work for both scaling and scrolling case.
-  static float TimeForBoundsToIntersect(const gfx::RectF& previous_bounds,

[epennerAtGoogle, 2014/02/03 23:43:03]

There is a tidbit in here that it might be nice to capture in the new solution
somehow. The new distance calculation is not skewed in any way by different x/y
velocities. So if we are scrolling downwards with just a touch of movement to
the left, we'll paint the left tiles much more eagerly than we should. The
bigger the 'time window' is for the skewport, the worse this will get.

One approach I can think of is stretching the x/y dimensions where the Manhattan
distance takes place. Or getting both X/Y components from the Manhattan
distance, and scaling those accordingly before adding them.

[vmpstr, 2014/02/04 19:50:49]

It's somewhat awkward to do this, I think. The problem is that it's not evident
from the skewport calculation whether the viewport will actually intersect the
tiles to the left/right when it's moving mostly down. Right now it  basically
assumes that it will (thus in a diagonal viewport move, it will result in a
larger than necessary skewport; see the unittests that I've added). 

I'm somewhat conflicted here. My gut feeling is that it's not really worth the
added complexity to figure out exactly which tiles will intersect the viewport
and which won't in a two direction scroll, since we're going back to being extra
correct but slow instead of just being roughly correct and fast. Wdyt?

[epennerAtGoogle, 2014/02/04 21:34:12]

I don't think correcting for this particular issue would be slow. But it would
require fudging something to get the right ordering.

I'm okay just leaving it for now... but if so we should just verify it doesn't
become a problem in practice. There is a chance that some
'fling-direction-snapping' removes small diagonal components already, which
would also solve this for the most part.

-                                        const gfx::RectF& current_bounds,
-                                        float time_delta,
-                                        const gfx::RectF& target_bounds);
-
   bool operator ==(const TilePriority& other) const {
     return resolution == other.resolution &&
-        time_to_visible_in_seconds == other.time_to_visible_in_seconds &&
-        distance_to_visible_in_pixels == other.distance_to_visible_in_pixels &&
+        priority_bin == other.priority_bin &&
+        distance_to_visible == other.distance_to_visible &&
         required_for_activation == other.required_for_activation;
   }
 
@@ -99,10 +102,12 @@ struct CC_EXPORT TilePriority {
 
   TileResolution resolution;
   bool required_for_activation;
-  float time_to_visible_in_seconds;
-  float distance_to_visible_in_pixels;
+  PriorityBin priority_bin;
+  float distance_to_visible;
 };
 
+scoped_ptr<base::Value> TilePriorityBinAsValue(TilePriority::PriorityBin bin);
+
 enum TileMemoryLimitPolicy {
   // Nothing.
   ALLOW_NOTHING = 0,