android_webview: changes to support Android GraphicBuffers

cc/resources/graphic_buffer.h

+// Copyright 2013 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_GRAPHIC_BUFFER_H_
+#define CC_RESOURCES_GRAPHIC_BUFFER_H_
+
+#include "base/basictypes.h"
+#include "base/callback.h"
+#include "base/memory/scoped_ptr.h"
+
+namespace gfx {
+class Size;
+}
+
+namespace cc {
+
+// Interface for creating and accessing a zero-copy buffer such as GraphicBuffer
+// of Android framework.
+class GraphicBuffer {

[joth, 2013/04/02 19:12:11]

can we make and statements about the thread safety of this class?

[kaanb, 2013/04/02 23:16:54]

Done.

+ public:
+  // This factory is called in ResourceProvider::CreateGraphicBuffer() to

[joth, 2013/04/02 19:12:11]

this comment is incorrect w.r.t this patch in isolation. (no other cc/ code is
using GraphicBuffer at all).

Also, rater than where it's used from, I'm more interested in what is the public
API I tell cc/ which factory it should be using. e.g. Is there a setter
somewhere?

[kaanb, 2013/04/02 23:16:54]

Done.

+  // create new instances.
+  typedef base::Callback<scoped_ptr<cc::GraphicBuffer>(const gfx::Size&)>
+      Factory;
+  virtual ~GraphicBuffer() {}
+
+  // Locks the buffer for the usage specified so the client
+  // can read or write the bitmap data in |*vaddr| subsequently.
+  // Returns 0 on success, non-zero on failure.
+  virtual bool LockForRead(void** vaddr) = 0;
+  virtual bool LockForWrite(void** vaddr) = 0;
+  // Unlocks the buffer. Returns 0 on success, non-zero otherwise.

[joth, 2013/04/02 19:12:11]

Also document:-
1/ can LockForRead be followed by LockForWrite (lock upgrade) or is Unlock the
only valid call after either Lock?
2/ if you can upgrade the lock, how many Unlock callss are needed?
3/ is it ok to call Unlock() even when it's not locked?
4/ is it Ok to destruct while still locked.

[kaanb, 2013/04/02 23:16:54]

Actually the Lock() is somewhat of a misnomer. Looks like the rest of the
compositor uses Map/Unmap for the same concept. There aren't any mutex style
synchronization primitives involved in these operations. I added more comments
on these methods though.

+  virtual bool Unlock() = 0;
+  // Returns the size of the buffer
+  virtual gfx::Size GetSize() = 0;
+  // Returns the native pointer for the graphic buffer.
+  virtual void* GetNativeBuffer() = 0;
+  // Returns the stride for the graphic buffer.
+  virtual uint32 GetStride() = 0;
+};
+
+}  // namespace cc
+
+#endif  // CC_RESOURCES_GRAPHIC_BUFFER_H_