cc: Optimize decode scheduling for checker-images.

cc/tiles/tile_manager.cc

Index: cc/tiles/tile_manager.cc
diff --git a/cc/tiles/tile_manager.cc b/cc/tiles/tile_manager.cc
index 9a63601f1518184dd63558e00ee15bddb0943dc2..9e5d3558f73d4f005d2f095ed9f6737f3b6888f5 100644
--- a/cc/tiles/tile_manager.cc
+++ b/cc/tiles/tile_manager.cc
@@ -691,7 +691,7 @@ TileManager::PrioritizedWorkToSchedule TileManager::AssignGpuMemoryToTiles() {
     tile->scheduled_priority_ = schedule_priority++;
 
     DCHECK(tile->draw_info().mode() == TileDrawInfo::OOM_MODE ||
-           !tile->draw_info().IsReadyToDraw());
+           !tile->draw_info().IsReadyToDraw() || tile->is_checker_imaged());
 
     // If the tile already has a raster_task, then the memory used by it is
     // already accounted for in memory_usage. Otherwise, we'll have to acquire
@@ -801,6 +801,7 @@ void TileManager::ScheduleTasks(
   size_t priority = kTileTaskPriorityBase;
 
   graph_.Reset();
+  checker_image_tracker_.ResetImageDecodeQueue();
 
   gfx::ColorSpace target_color_space = client_->GetTileColorSpace();
 
@@ -819,7 +820,20 @@ void TileManager::ScheduleTasks(
     Tile* tile = prioritized_tile.tile();
 
     DCHECK(tile->draw_info().requires_resource());
-    DCHECK(!tile->draw_info().resource());
+    DCHECK(!tile->draw_info().resource() || tile->is_checker_imaged());
+
+    bool process_tile_for_checker_images_only = tile->draw_info().resource();
+    if (process_tile_for_checker_images_only) {
+      std::vector<DrawImage> images;
+      ImageIdFlatSet checkered_images;
+      prioritized_tile.raster_source()->GetDiscardableImagesInRect(
+          tile->enclosing_layer_rect(), tile->contents_scale(), &images);
+      checker_image_tracker_.FilterImagesForCheckeringForTile(

[vmpstr, 2017/03/07 19:25:08]

Yeah I think filter might be a bad name since from here it looks like you're
partitioning the images into two sets and then discarding this information. Btw,
when do we unlock these images?

[Khushal, 2017/03/13 20:35:08]

I pulled that function into the TileManager. Does filter make sense now?
And we unlock the images after the sync tree on which they were invalidated has
been activated. They could be unlocked earlier, may be after we've built the
raster tasks following the invalidation, since that should add the necessary
refs.

+          &images, &checkered_images, tile->tiling()->tree());
+      DCHECK(!checkered_images.empty())
+          << "Checker-imaged state is sticky on a Tile";
+      continue;
+    }
 
     if (!tile->raster_task_) {
       tile->raster_task_ =
@@ -970,6 +984,8 @@ scoped_refptr<TileTask> TileManager::CreateRasterTask(
         tile->enclosing_layer_rect(), tile->contents_scale(), &images);
     checker_image_tracker_.FilterImagesForCheckeringForTile(
         &images, &images_to_skip, prioritized_tile.tile()->tiling()->tree());
+    if (!images_to_skip.empty())
+      tile->set_is_checker_imaged();

[vmpstr, 2017/03/07 19:25:08]

When is this flag reset?

[Khushal, 2017/03/13 20:35:08]

Its not. If a tile is checker-imaged. It can only be replaced by another tile.
This state is never changed for a particular tile once set.

   }
 
   // We can skip the image hijack canvas if we have no images, or no images to