cc: Disallow img.decode images from being checker imaged.

cc/tiles/checker_image_tracker.cc

Index: cc/tiles/checker_image_tracker.cc
diff --git a/cc/tiles/checker_image_tracker.cc b/cc/tiles/checker_image_tracker.cc
index 022269d87a95fa52d4661581e4c527c4799f32d4..35c19e2d6160d18e43d8df777a58f60709988cce 100644
--- a/cc/tiles/checker_image_tracker.cc
+++ b/cc/tiles/checker_image_tracker.cc
@@ -88,16 +88,24 @@ void CheckerImageTracker::ClearTracker(bool can_clear_decode_policy_tracking) {
     // re-decode and checker images that were pending invalidation.
     for (auto image_id : images_pending_invalidation_) {
       auto it = image_async_decode_state_.find(image_id);
-
       DCHECK(it != image_async_decode_state_.end());
-      DCHECK_EQ(it->second, DecodePolicy::SYNC_DECODED_ONCE);
 
+      // We might have disallowed checkering for this image while it was pending
+      // invalidation. Ensure that we keep this information.
+      if (it->second == DecodePolicy::SYNC_PERMANENT)
+        continue;
+
+      DCHECK_EQ(it->second, DecodePolicy::SYNC_DECODED_ONCE);
       it->second = DecodePolicy::ASYNC;
     }
   }
   images_pending_invalidation_.clear();
 }
 
+void CheckerImageTracker::DisallowCheckeringForImage(const PaintImage& image) {
+  image_async_decode_state_[image.stable_id()] = DecodePolicy::SYNC_PERMANENT;

[Khushal, 2017/06/07 00:47:21]

I think if the image was already seen by the tracker, then we have to continue
checkering it. Because we now we have checker-imaged tiles and we are
responsible for invalidating them.

[vmpstr, 2017/06/07 17:05:35]

Makes sense. I've added a separate container for tracking this so that it
doesn't get muddied with the current state. The new behavior should be that if
we already know the state of the image in the decode state, then it will use
that. However, when inserting a new state it will consider whether it's
disallowed or not.

I've also changed the clear function a little bit so that instead of marking
images as async if they were sync decoded with pending invalidations, instead
they just get deleted from the state. This would again make then async when we
check if we should checker them, unless of course they were disallowed
meanwhile. I think this is fine, since we clear the pending invalidation set
anyway, so we know there are no tiles right now. Is that correct? 

In other words, if we are "soft" clearing the tracker, then that means we're not
visible which means we've evicted all tiles. If that wouldn't be the case, then
we can't clear the images pending invalidation, afaict.

+}
+
 void CheckerImageTracker::DidFinishImageDecode(
     PaintImage::Id image_id,
     ImageController::ImageDecodeRequestId request_id,
@@ -119,7 +127,10 @@ void CheckerImageTracker::DidFinishImageDecode(
     return;
   }
 
-  it->second = DecodePolicy::SYNC_DECODED_ONCE;
+  // We might have disallowed checkering for this image while it was being
+  // processed. Ensure that the stronger condition is recorded.
+  if (it->second != DecodePolicy::SYNC_PERMANENT)
+    it->second = DecodePolicy::SYNC_DECODED_ONCE;
   images_pending_invalidation_.insert(image_id);
   ScheduleNextImageDecode();
   client_->NeedsInvalidationForCheckerImagedTiles();