Add a path to use CALayers to display content

content/browser/renderer_host/compositing_iosurface_layer_mac.h

+// Copyright (c) 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 CONTENT_BROWSER_RENDERER_HOST_COMPOSITING_IOSURFACE_LAYER_MAC_H_
+#define CONTENT_BROWSER_RENDERER_HOST_COMPOSITING_IOSURFACE_LAYER_MAC_H_
+
+#import <Cocoa/Cocoa.h>
+
+#include "base/mac/scoped_cftyperef.h"
+#include "base/memory/ref_counted.h"
+
+namespace content {
+class CompositingIOSurfaceContext;
+class RenderWidgetHostViewMac;
+}
+
+// The CoreAnimation layer for drawing accelerated content.
+@interface CompositingIOSurfaceLayer : CAOpenGLLayer {
+ @private
+  content::RenderWidgetHostViewMac* renderWidgetHostView_;
+  scoped_refptr<content::CompositingIOSurfaceContext> context_;
+}
+
+@property(nonatomic, readonly)
+    scoped_refptr<content::CompositingIOSurfaceContext> context;
+
+- (id)initWithRenderWidgetHostViewMac:(content::RenderWidgetHostViewMac*)r;
+
+// The OpenGL context may be destroyed periodically (e.g, when moving across
+// displays). This will re-allocate the context if need be, and returns whether

[Ken Russell (switch to Gerrit), 2013/06/03 22:05:01]

Does this code path properly support switching the OpenGL context the
CompositingIOSurfaceLayer uses? Specifically, the CAOpenGLLayer will call
copyCGLContextForPixelFormat at some unspecified time and cache the result. It
looks to me like there is a problem when the RWHVMac switches which window it is
rendering to. I think this could be provoked by dragging an accelerated tab to a
new window.

If there is a problem, associating these CompositingIOSurfaceLayers differently
may solve it -- so that they can be destroyed and re-created when the RWHVMac
switches to a new window.

[ccameron, 2013/06/03 22:14:59]

This doesn't support forcibly changing the underlying context. So if you drag a
tab between windows, your performance may suffer from using the same GL context
to draw two visible windows. It may also be that using the same GL context for
all windows doesn't have the negative effects that it did in the other path (in
which case we can go to just sharing one context globally). I'll need to
investigate this before making this path the default. Your suggestion of
removing the layer and adding a new one will definitely fix the issue.

[Ken Russell (switch to Gerrit), 2013/06/03 22:36:19]

OK. My concern is only about correctness -- whether it will try to do something
like render with the wrong context, or to a context bound to the wrong drawable.

Can be worked on in future CLs.

+// or not the context now exists.
+- (BOOL)ensureContext;
+
+// Update the scale factor of the layer to match the scale factor of the
+// IOSurface.
+- (void)updateScaleFactor;
+
+// Remove this layer from the layer heirarchy, and mark that
+// |renderWidgetHostView_| is no longer valid and may no longer be dereferenced.
+- (void)disableCompositing;
+
+@end
+
+#endif  // CONTENT_BROWSER_RENDERER_HOST_COMPOSITING_IOSURFACE_LAYER_MAC_H_