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

cc/resources/raster_buffer.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_RESOURCES_RASTER_BUFFER_H_
 #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
 
 #endif  // CC_RESOURCES_RASTER_BUFFER_H_