cc: Make pending visible rect active tree tiles be in the NOW bin.

cc/tiles/raster_tile_priority_queue_all.cc

Index: cc/tiles/raster_tile_priority_queue_all.cc
diff --git a/cc/tiles/raster_tile_priority_queue_all.cc b/cc/tiles/raster_tile_priority_queue_all.cc
index a197b1284380dc9f7c96dbae2bb65543cc550334..0d54a592607ee0558de53349c83fdde3c0aaf86a 100644
--- a/cc/tiles/raster_tile_priority_queue_all.cc
+++ b/cc/tiles/raster_tile_priority_queue_all.cc
@@ -145,14 +145,16 @@ RasterTilePriorityQueueAll::GetNextQueues() const {
 
   switch (tree_priority_) {
     case SMOOTHNESS_TAKES_PRIORITY: {
-      // If we're down to eventually bin tiles on the active tree and there
-      // is a pending tree, process the entire pending tree to allow tiles
-      // required for activation to be initialized when memory policy only
-      // allows prepaint. The eventually bin tiles on the active tree are
-      // lowest priority since that work is likely to be thrown away when
-      // we activate.
-      if (active_priority.priority_bin == TilePriority::EVENTUALLY)
+      // If we're down to soon bin tiles on the active tree and there
+      // is a pending tree, process the now tiles in the pending tree to allow
+      // tiles required for activation to be initialized when memory policy only
+      // allows prepaint. The soon/eventually bin tiles on the active tree are
+      // lowest priority since that work is likely to be thrown away when we
+      // activate.
+      if (active_priority.priority_bin >= TilePriority::SOON &&

[sunnyps, 2016/10/10 20:22:31]

Not blocking this CL but can we have a test for this behavior i.e. active tree
has SOON tiles and pending tree has NOW tiles.

[vmpstr, 2016/10/10 20:26:12]

I think the test I updated covers this, but I'll add more.

+          pending_priority.priority_bin == TilePriority::NOW) {
         return pending_queues_;
+      }
       return active_queues_;
     }
     case NEW_CONTENT_TAKES_PRIORITY: {