Expose locks for CopyFromCompositingSurface/CopyFromBackingStore API

content/public/browser/render_widget_host.h

Index: content/public/browser/render_widget_host.h
diff --git a/content/public/browser/render_widget_host.h b/content/public/browser/render_widget_host.h
index 2eb913b2ab54edd40aac2a52045b46088b37cba3..7086697a6e679f56b41a1e4d5ac774776878b17f 100644
--- a/content/public/browser/render_widget_host.h
+++ b/content/public/browser/render_widget_host.h
@@ -200,6 +200,10 @@ class CONTENT_EXPORT RenderWidgetHost : public IPC::Sender {
       const gfx::Rect& src_rect,
       const gfx::Size& accelerated_dst_size,
       const base::Callback<void(bool, const SkBitmap&)>& callback) = 0;
+  virtual bool CanCopyFromBackingStore() = 0;

[jam, 2014/02/26 00:09:54]

so to be clear, this is in the public api since chrome on android, which isn't
in this repository, is calling these methods?

[no sievers, 2014/02/26 00:25:56]

Actually we don't have to add this one. It already exists in
content/public/render_widget_host_view.h:
 // Returns true is the current display surface is available.
  virtual bool IsSurfaceAvailableForCopy() const = 0;

[powei, 2014/02/26 18:42:38]

I thought it would make sense that the user would just interact with
RenderWidgetHost and not have to worry about whether the view is there or not. 
WDYT? 

+  // Ensures that the view does not drop the backing store even when hidden.
+  virtual void LockForCopyFromBackingStore() = 0;
+  virtual void UnlockForCopyFromBackingStore() = 0;

[jam, 2014/02/26 00:09:54]

I'm sure there's a reason why you're exposing these methods, but right now I'm
not seeing it.

Per the cl subject, you're doing this so that the content isn't evicted when
calling async CopyFromBackingStore/CopyFromCompositingSurface. But I don't
understand why you need public locking methods. Why can't the implementation of
CopyFromBackingStore/CopyFromCompositingSurface do this internally since they
know when there's an oustanding callback?

[no sievers, 2014/02/26 00:25:56]

The problem is that the application wants to replace the live tab with a
placeholder approximation which needs to happen asynchronously.

While this happens and until this is ready and added to the compositor tree, we
cannot let RWHV release the live surface.

It's sort of an override for 'frontbuffer' memory management which the app is
not really involved in.

[jam, 2014/02/26 17:37:29]

I'm not familiar with this part of the code, so I have more questions. When this
"replace the live tab with a placeholder" is happening, at that point a pending
CopyFromBackingStore/CopyFromCompositingSurface is happening? I'm just trying to
convince myself that we can't implement this internally without a public API.
It's hard to see the whole picture because I don't see the calling code. I also
don't understand why these lock methods are empty (see my other comment)

 #if defined(TOOLKIT_GTK)
   // Paint the backing store into the target's |dest_rect|.
   virtual bool CopyFromBackingStoreToGtkWindow(const gfx::Rect& dest_rect,