cc: Partial tile update for one-copy raster.

cc/raster/tile_task_runner.h

Index: cc/raster/tile_task_runner.h
diff --git a/cc/raster/tile_task_runner.h b/cc/raster/tile_task_runner.h
index 234ca6f04ab5fc2be423e5d775de7e79cc99c27b..fd251eec851a8423c9a905cd1a7ef14d83854c40 100644
--- a/cc/raster/tile_task_runner.h
+++ b/cc/raster/tile_task_runner.h
@@ -11,6 +11,7 @@
 #include "base/callback.h"
 #include "cc/raster/task_graph_runner.h"
 #include "cc/resources/resource_format.h"
+#include "ui/gfx/geometry/rect.h"

[reveman, 2015/05/28 05:07:25]

don't think you need this anymore

[danakj, 2015/05/28 18:54:47]

Done.

 
 namespace cc {
 class ImageDecodeTask;
@@ -18,10 +19,23 @@ class RasterTask;
 class Resource;
 class RasterBuffer;
 
+struct TileTaskData {

[reveman, 2015/05/28 05:07:24]

not a fan of things named "data", "info", etc. can we instead just pass what is
needed as parameters to AcquireBufferForRaster?

[danakj, 2015/05/28 18:54:47]

I can. Every time we add a new parameter it requires touching like 20 files
(look at this CL) whereas a struct would let us touch a lot less - just the
places that use it. I agree "Data" isn't a generally useful name, this is just
the parameters for AcquireBufferForRaster. I could call it AcquireBufferData?
AcquireBufferParams? Something else?

+  TileTaskData(const Resource* resource,
+               uint64_t new_content_id,
+               uint64_t previous_content_id)
+      : resource(resource),
+        new_content_id(new_content_id),
+        previous_content_id(previous_content_id) {}
+
+  const Resource* resource;
+  uint64_t new_content_id;
+  uint64_t previous_content_id;
+};
+
 class CC_EXPORT TileTaskClient {
  public:
   virtual scoped_ptr<RasterBuffer> AcquireBufferForRaster(
-      const Resource* resource) = 0;
+      const TileTaskData& data) = 0;
   virtual void ReleaseBufferForRaster(scoped_ptr<RasterBuffer> buffer) = 0;

[reveman, 2015/05/28 05:07:25]

Discussed this with Vlad and I think there are some minor changes that can be
made to make this API easier to understand from the tile manager's point of
view. What if the interface and the tile manager usage looked like this:

// Acquires a buffer for raster to |resource|. The buffer should preferably
// be populated with contents matching |preferred_content_id|. The actual
// contents of the buffer is returned in |actual_content_id|.
virtual scoped_ptr<RasterBuffer> AcquireBufferForRaster(
    const Resource* resource,
    uint64_t preferred_content_id,
    uint64_t* actual_content_id);

// Releases a previously acquired buffer. |content_id| uniquely identifies the
// contents of the buffer.
virtual void ReleaseBufferForRaster(scoped_ptr<RasterBuffer> buffer,
                                    uint64_t content_id);


RasterBufferImpl in tile manager would do:

void ScheduleOnOriginThread(TileTaskClient* client) override {
  raster_buffer_ = client->AcquireBufferForRaster(
      resource(), previous_content_id_, &raster_buffer_content_id_);
}
void Raster(const RasterSource* raster_source) {
  gfx::Rect playback_rect =
      raster_buffer_content_id_ == previous_content_id_ ?
      dirty_content_rect_ : content_rect_;
  
  raster_buffer_->Playback(raster_source_.get(),
                           playback_rect,
                           contents_scale_);
}
void CompleteOnOriginThread(TileTaskClient* client) override {
  client->ReleaseBufferForRaster(raster_buffer_.Pass(), new_content_id_);
}

The idea is that the flow would become a bit easier to understand. We acquire a
buffer, decide what part of the raster source to playback based on the result of
that and then release the raster buffer when done while also providing a new
content id the represents the result of the raster done to the buffer.

Wdyt? 

[danakj, 2015/05/28 18:54:47]

This doesn't work. Tile manager doesn't know if the ResourcePool has a resource
with the old content ID. The worker pool needs both rects and needs to decide
which one to raster based on if it finds the old content ID resource or not.
I think that this doesn't really work and we should figure out what bitmap and
gpu raster partial raster works before trying to rewrite APIs.

[reveman, 2015/05/29 14:50:26]

The whole point of the interface suggestion above would be to let the tile
manager code know what the content of the raster buffer is so it can make the
right decision for what needs to be done in terms of raster.
Ok, let's discuss that today if you have time.

 
  protected: