cc: Clear checker-image tracking on navigation and visibility changes.

cc/trees/layer_tree_host_impl.cc

Index: cc/trees/layer_tree_host_impl.cc
diff --git a/cc/trees/layer_tree_host_impl.cc b/cc/trees/layer_tree_host_impl.cc
index b8d25afce74bc79b87f99037202737c75b5e928c..458fecab85fe70a388fbc49ddc83c775159d2fb8 100644
--- a/cc/trees/layer_tree_host_impl.cc
+++ b/cc/trees/layer_tree_host_impl.cc
@@ -1280,6 +1280,11 @@ void LayerTreeHostImpl::UpdateTileManagerMemoryPolicy(
     // running work.
     if (image_decode_cache_)
       image_decode_cache_->SetShouldAggressivelyFreeResources(false);
+  } else {
+    // Clear checkered image state so we unlock cached images. Since we will be
+    // evicting all tile resources and images from the ImageDecodeCache, this
+    // also ensures that we re-checker these images.
+    tile_manager_.ClearCheckerImageTracking();

[vmpstr, 2017/05/09 22:06:21]

Can you verify what happens in a resourceless software draw for a webview? I
think we might set the memory limit to 0 there as well or is that not true?

[Khushal, 2017/05/10 00:53:17]

Do you think this is okay for the general case? In particular I'm considering
how this will interact with partial raster. If we are able to acquire any
resources on becoming visible, we might trigger re-raster only for some tiles,
on which images will be checkered. And when that decode finishes, it will cause
an invalidation for all tiles with that image on the next pending tree.

   }
 
   DCHECK(resource_pool_);
@@ -2339,6 +2344,7 @@ LayerTreeHostImpl::TakeCompletedImageDecodeCallbacks() {
 }
 
 void LayerTreeHostImpl::ClearImageCacheOnNavigation() {
+  tile_manager_.ClearCheckerImageTracking();
   if (image_decode_cache_)
     image_decode_cache_->ClearCache();
 }