cc: Partial tile update for one-copy raster.

cc/raster/tile_task_runner.h

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef CC_RASTER_TILE_TASK_RUNNER_H_
 #define CC_RASTER_TILE_TASK_RUNNER_H_
 
 #include <bitset>
 #include <vector>
 
 #include "base/callback.h"
 #include "cc/raster/task_graph_runner.h"
 #include "cc/resources/resource_format.h"
+#include "ui/gfx/geometry/rect.h"
 
 namespace cc {
 class ImageDecodeTask;
 class RasterTask;
 class Resource;
 class RasterBuffer;
 
+struct TileTaskData {
+  TileTaskData(const Resource* resource,
+               uint64_t new_tile_id,
+               uint64_t previous_tile_id,
+               const gfx::Rect& raster_dirty_rect)
+      : resource(resource),
+        new_tile_id(new_tile_id),
+        previous_tile_id(previous_tile_id),
+        raster_dirty_rect(raster_dirty_rect) {}
+
+  const Resource* resource;
+  uint64_t new_tile_id;
+  uint64_t previous_tile_id;
+  gfx::Rect raster_dirty_rect;
+};

[reveman, 2015/05/22 17:15:13]

If I understand this correctly, here's how this works (please correct me where
wrong).

1. We're basically implementing discardable resources. Each resource is assigned
an ID that uniquely identifies the content. We can then later lookup this
resource using the ID to find out if it has been discarded (reused or deleted)
or not. If not, great! We'll reuse it.

2. We keep track the dirty rect of a tile compared to the contents of the
previously rasterized tile.

3. If the old resource has not been discarded, we use it to only rasterize the
dirty rect.

Questions

Can we implement discardable resources as a content ID in the Resource class
instead? I think that would make that part of the system easier to understand as
it would be independent of our tile management system. Each Resource instance
would have a contents ID or a generation ID (think skia's pixelrefs). The
Resource class would be responsible for generating unique IDs as a result of
something like Resource::ContentsChanged() being called. Wdyt?

Do we really need to pass everything in TileTaskData to AcquireBufferForRaster?
Is the Resource that we need a raster buffer for and the contents ID not
sufficient? I think it would be more appropriate to pass the dirty rect as the
|rect| param to RasterBuffer::Playback.

[danakj, 2015/05/26 19:02:52]

Correct.
I like the idea of calling this a "content id", that makes a lot of sense.

I don't think this should live on the Resource. This is something that is being
implemented by ResourcePool and only the pool needs to know about it. It
provides a way to reuse resources in the pool based on the id. No other users of
ResourceId need to worry about this.
This seems good! I was just unaware of how everything fits together. Let me try
that out.

[reveman, 2015/05/26 20:12:37]

I was thinking the cc::Resource class and not the ResourceId. Either way,
keeping it in the resource pool is fine if you think that's more appropriate.
Cool.

+
 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;
 
  protected:
   virtual ~TileTaskClient() {}
 };
 
 class CC_EXPORT TileTask : public Task {
  public:
   typedef std::vector<scoped_refptr<TileTask>> Vector;
 
@@ skipping 128 matching lines @@
   // Returns the format to use for the tiles.
   virtual ResourceFormat GetResourceFormat() = 0;
 
  protected:
   virtual ~TileTaskRunner() {}
 };
 
 }  // namespace cc
 
 #endif  // CC_RASTER_TILE_TASK_RUNNER_H_