cc: Replace RasterBuffer::Acquire/ReleaseCanvas with Playback function.

cc/resources/raster_buffer.h

Index: cc/resources/raster_buffer.h
diff --git a/cc/resources/raster_buffer.h b/cc/resources/raster_buffer.h
index d148b72dfe5a913e805b46fe27e8f9166ff0420a..df7ea5fe20bc1f70298a068dc678382903822ced 100644
--- a/cc/resources/raster_buffer.h
+++ b/cc/resources/raster_buffer.h
@@ -6,19 +6,21 @@
 #define CC_RESOURCES_RASTER_BUFFER_H_
 
 #include "cc/base/cc_export.h"
-#include "skia/ext/refptr.h"
-
-class SkCanvas;
+#include "ui/gfx/geometry/rect.h"
 
 namespace cc {
+class PicturePileImpl;
+class RenderingStatsInstrumentation;
 
 class CC_EXPORT RasterBuffer {
  public:
   RasterBuffer();
   virtual ~RasterBuffer();
 
-  virtual skia::RefPtr<SkCanvas> AcquireSkCanvas() = 0;
-  virtual void ReleaseSkCanvas(const skia::RefPtr<SkCanvas>& canvas) = 0;
+  virtual void Playback(const PicturePileImpl* picture_pile,

[vmpstr, 2014/10/15 00:09:30]

I'm not really a fan of this leaking to RasterBuffer, since picture pile impl is
really only the current approach of doing this, but I guess that's fine since
for the time being we're fairly committed to having picture likes, rects, and
scales...

[reveman, 2014/10/15 01:24:06]

Yes, I'm a bit annoyed by this too but the cleanup we get from doing it makes me
feel that it's worth it.

We could always add multiple functions to this interface. For example:

virtual void PlaybackPicturePile(... );
virtual void ExecuteAwesomeDisplayList(... );

Or we can create some other interface that PicturePileImpl could implement and
RasterBuffer would use. That seems like an unnecessary abstraction at this point
though..

+                        const gfx::Rect& rect,
+                        float scale,
+                        RenderingStatsInstrumentation* stats) = 0;
 };
 
 }  // namespace cc