cc: Simplify picture layer tiling update tile priorities.

cc/resources/managed_tile_state.h

Index: cc/resources/managed_tile_state.h
diff --git a/cc/resources/managed_tile_state.h b/cc/resources/managed_tile_state.h
index 5379056af2cb9816448e21ada5036277114aee29..2843169977d68801e373ae140f543a12cdaf4d90 100644
--- a/cc/resources/managed_tile_state.h
+++ b/cc/resources/managed_tile_state.h
@@ -111,8 +111,8 @@ class CC_EXPORT ManagedTileState {
 
   TileResolution resolution;
   bool required_for_activation;
-  float time_to_needed_in_seconds;
-  float distance_to_visible_in_pixels;
+  TilePriority::PriorityBin priority_bin;
+  float distance_to_visible;

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

Since we plan on 'augmenting' this distance in various ways to cram most of our
priority into it, should we put that into the name?  I can't think of a better
name though ('distance_based_metric'?), so I have no strong preference on the
name.

[enne (OOO), 2014/02/04 00:38:22]

I thought we would be able to use this really as distance to visible but use an
explicit bin as the higher order sorting bit.  So, something in the apron might
be closer but in the EVENTUALLY bin than something farther away in the
skewport+SOON bin, and we'll sort the SOON before the EVENTUALLY.

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

I initially considered doing a single metric, by boosting the skewport (like
dividing the distance by some value or something like that). However, I think
that makes it sensitive to skewport target time and things like that as some
tiles near the end of the skewport will be sorted lower than near viewport soon
tiles. I would vote for keeping the bins since it makes it very clear where the
tile is coming from and having the distance only come into play when figuring
out priorities within a bin.

Later, if this is a good spot for optimization then I'm sure we can figure out a
single metric.

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

SGTM. Cramming into one priority can wait, and only if it doesn't get too messy.

My thought was, if the skewport had a size limit, that limit could be added to
all non-skewport tiles, to differentiate in-skewport tiles from other tiles...
But no need to go there yet, or maybe never if we can't remove the other sources
of complex priority decisions (eg. smoothness/resolution).

   bool visible_and_ready_to_draw;
 
   // Priority for this state from the last time we assigned memory.