cc: Simplify picture layer tiling update tile priorities.

cc/resources/tile_manager.cc

Index: cc/resources/tile_manager.cc
diff --git a/cc/resources/tile_manager.cc b/cc/resources/tile_manager.cc
index 4f9f0aed6545b1792c93111f34313194c1268288..37b9fa1f965fd871ae4e7d3358a7ab9b1e9295cd 100644
--- a/cc/resources/tile_manager.cc
+++ b/cc/resources/tile_manager.cc
@@ -115,38 +115,16 @@ const ManagedTileBin kBinIsActiveMap[2][NUM_BINS] = {
 // Determine bin based on three categories of tiles: things we need now,
 // things we need soon, and eventually.
 inline ManagedTileBin BinFromTilePriority(const TilePriority& prio) {
-  // The amount of time/pixels for which we want to have prepainting coverage.
-  // Note: All very arbitrary constants: metric-based tuning is welcome!
-  const float kPrepaintingWindowTimeSeconds = 1.0f;
-  const float kBackflingGuardDistancePixels = 314.0f;

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

As is, some platforms use a 'soon-only-memory-policy'. When we remove the
'fling-guard' and use skewport->soon in this patch, we will have effectively no
pre-painted tiles unless you are scrolling when using that policy.

To not regress painting behavior, we should somehow maintain the 'fling-guard'
part of the SOON_BIN, until the binning process can be sorted out or removed.

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

This actually doesn't just provide the fling back, but also a border around the
visible tiles. In the long term, this would be provided by the eventually bin
from the layer (currently it's all of interest rect that falls into this
category). For now we can do the same distance check here or extend the skewport
backwards. I'm opting in for distance check.

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

Right, it's not just fling-back, but sort of a small piece of 'interest-rect'
that gets promoted to the soon-bin.

It sounds good to just keep a distance check in here.... However, unfortunately
the simple distance metric bites us again as all these tiles have a small
distance. So we'll keep painting these tiles rather than the extruded skewport
tiles in the direction of a scroll.

If we don't augment the distance, it looks like creating another bin, or another
'in-skewport' flag would solve it for now? Or maybe we can just accept the
checker-boarding hit for soon-only-memory-policy in the short term.

[vmpstr, 2014/02/04 21:57:53]

I think here we're actually saved by bin and distance calculations from the
tiling:

Skewport tiles will have TilePriority::SOON + distance, other interest rect
tiles will be TilePriority::EVENTUALLY + distance. Skewport tiles automatically
get ManagedTileBin::SOON_BIN (SOON -> SOON_BIN), and interest rect tiles closer
than backfling guard will also be promoted to ManagedTileBin::SOON_BIN
(EVENTUALLY + small distance -> SOON_BIN). In the BinComparator, the first check
is now for the TilePriority bin, which would order skewport tiles
(TilePriority::SOON) over backfling guarded tiles (TilePriority::EVENTUALLY).
It's somewhat confusing to have two distinct sets of bins both with similar
names, but hopefully we can get rid of ManagedTileBin stuff as we make progress
in the redesign.

[epennerAtGoogle, 2014/02/04 23:48:06]

Oh, I see. Indeed that's confusing but indeed that sounds like it will work :)

We definitely need to get rid of parallel bin concepts, but this sounds like it
preserves the functionality we need in the interim.

-  // Note: The max distances here assume that SOON_BIN will never help overcome
-  // raster being too slow (only caching in advance will do that), so we just
-  // need enough padding to handle some latency and per-tile variability.
-  const float kMaxPrepaintingDistancePixelsHighRes = 2000.0f;

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

This limit was effectively a velocity limit. I think if we remove this we should
have a limit on the viewport edge velocities, or a limit on the skewport's
extruded size.

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

I've done this via skewport capping. Let me know if that works.

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

SGTM.

-  const float kMaxPrepaintingDistancePixelsLowRes = 4000.0f;
-
-  if (prio.distance_to_visible_in_pixels ==
-      std::numeric_limits<float>::infinity())
-    return NEVER_BIN;
-
-  if (prio.time_to_visible_in_seconds == 0)
+  if (prio.priority_bin == TilePriority::NOW)
     return NOW_BIN;
 
-  if (prio.resolution == NON_IDEAL_RESOLUTION)
-    return EVENTUALLY_BIN;
-
-  float max_prepainting_distance_pixels =
-      (prio.resolution == HIGH_RESOLUTION)
-          ? kMaxPrepaintingDistancePixelsHighRes
-          : kMaxPrepaintingDistancePixelsLowRes;
-
-  // Soon bin if we are within backfling-guard, or under both the time window
-  // and the max distance window.
-  if (prio.distance_to_visible_in_pixels < kBackflingGuardDistancePixels ||
-      (prio.time_to_visible_in_seconds < kPrepaintingWindowTimeSeconds &&
-       prio.distance_to_visible_in_pixels <= max_prepainting_distance_pixels))
+  if (prio.priority_bin == TilePriority::SOON)
     return SOON_BIN;
 
+  if (prio.distance_to_visible ==
+      std::numeric_limits<float>::infinity())
+    return NEVER_BIN;
+
   return EVENTUALLY_BIN;
 }
 
@@ -448,9 +426,9 @@ void TileManager::GetTilesWithAssignedBins(PrioritizedTileSet* tiles) {
       mts.bin = tile_is_active ? AT_LAST_AND_ACTIVE_BIN : AT_LAST_BIN;
 
     mts.resolution = tile_priority.resolution;
-    mts.time_to_needed_in_seconds = tile_priority.time_to_visible_in_seconds;
-    mts.distance_to_visible_in_pixels =
-        tile_priority.distance_to_visible_in_pixels;
+    mts.priority_bin = tile_priority.priority_bin;
+    mts.distance_to_visible =
+        tile_priority.distance_to_visible;
     mts.required_for_activation = tile_priority.required_for_activation;
 
     mts.visible_and_ready_to_draw =
@@ -952,7 +930,7 @@ void TileManager::OnRasterTaskCompleted(
   }
 
   FreeUnusedResourcesForTile(tile);
-  if (tile->priority(ACTIVE_TREE).distance_to_visible_in_pixels == 0)
+  if (tile->priority(ACTIVE_TREE).distance_to_visible == 0.f)
     did_initialize_visible_tile_ = true;
 }