cc: Keep PaintImage in DrawImage.

cc/tiles/image_controller.cc

Index: cc/tiles/image_controller.cc
diff --git a/cc/tiles/image_controller.cc b/cc/tiles/image_controller.cc
index 698dc79e2510b8cf78edfc2239cfde3dff78b49c..6a955d954cfd72935aaf4b21cfde554c2523e065 100644
--- a/cc/tiles/image_controller.cc
+++ b/cc/tiles/image_controller.cc
@@ -22,6 +22,7 @@ ImageController::ImageController(
     scoped_refptr<base::SequencedTaskRunner> worker_task_runner)
     : worker_task_runner_(std::move(worker_task_runner)),
       origin_task_runner_(origin_task_runner),
+      paint_image_id_(PaintImage::GetNextId()),

[vmpstr, 2017/05/12 22:15:42]

This is something that we need to talk about I think. We need to be able to
plumb ... something.

Like, I think the cache should know the stable id for us to properly clean up
partially loaded images. Also, the checker tracker has to also never checker a
skia id which was decoded by the decode() call.

[Khushal, 2017/05/13 02:45:50]

We'll definitely need PaintImage plumbed to cc, instead of SkImage, for the
decode API. That shouldn't be difficult. And that should handle the
checker-imaging.

For clearing the caches, I think we should address that in the doc that
discusses unifying blink and cc's caching.

[vmpstr, 2017/05/15 15:02:55]

My concern is that it doesn't feel that we're cleanly defining the boundary
where PaintImage has data generated by blink and where it's being used as a
placeholder in draw images. I think we need to tune this to ensure that we
always get the right paint image (the id specifically). I think this should
naturally fall out from removing image hijack canvas, since we'll be passing the
right id there. 

the problem is that if I want to add any code that depends on the id into the
cache (such as clearing old entries), I need to know that each call has the
right id. If we sometimes pass the right id, and sometimes we just generate a
dummy one, then we'll end up in a situation where we might be clearing things we
didn't mean to, or not clearing things that we should.

[Khushal, 2017/05/15 21:22:14]

ImageHijackCanvas is one use-case. The other one is the decode API.
crbug.com/722559 has info about all these use-cases right now. The plumbing we
have so far is enough for the checker-imaging system, but the hijack canvas and
decode API will definitely need to be handled before the cache can make use of
this id.

       weak_ptr_factory_(this) {}
 
 ImageController::~ImageController() {
@@ -195,8 +196,10 @@ ImageController::ImageDecodeRequestId ImageController::QueueImageDecode(
   DCHECK(image);
   bool is_image_lazy = image->isLazyGenerated();
   auto image_bounds = image->bounds();
-  DrawImage draw_image(std::move(image), image_bounds, kNone_SkFilterQuality,
-                       SkMatrix::I(), target_color_space);
+  DrawImage draw_image(
+      PaintImage(paint_image_id_,
+                 sk_ref_sp(const_cast<SkImage*>(image.release()))),
+      image_bounds, kNone_SkFilterQuality, SkMatrix::I(), target_color_space);
 
   // Get the tasks for this decode.
   scoped_refptr<TileTask> task;