Add a path to use CALayers to display content

Add a path to use CALayers to display content

Add the flag --use-core-animation to enable this path.

Make the RenderWidgetHostViewCocoa layer-backed, and add a
default white layer.

Add a CALayer, softwareLayer_ to draw into when the accelerated
path is disabled. Update the software draw methods to use the CG
calls (this changes the non-CA path as well, but should be equivalent
to previous behavior).

If accelerated compositing is enabled, then add CAOpenGLLayer to
draw accelerated frames (frames using IOSurfaces). If we receive a
software frame, then delete this layer (and the software layer will
appear below it).

This still has a number of issues to resolve before enabling, including
- corrupted bookmark bars
- increased CPU usage (3.5%->5% without compositing, 7%->10% with)
- increased startup time

BUG=245900
NOTRY=True

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=204841

[ccameron, 2013-05-31 10:41:00]

This is part 1 of a sequence of 3 patches to move us to CoreAnimation
1. Add the path for composited pages (behind flag)
2. Add the path for non-composited pages (behind flag)
(okay, a couple of bugfixes here)
3. Make CoreAnimation the default and add a command line flag to disable it.

The division of 1 and 2 into separate changes is to keep the diffs minimal
and readable.

This is based largely on patches that sail@ has sent me.

[Nico, 2013-05-31 21:12:34]

"This is part 1 of a sequence of 3 patches" => needs tracking bug

The bug should have some kind of overview like Sail's mail had.

[ccameron, 2013-05-31 22:37:15]

I'll add a bug for this.

Actually, I'll keep this behind a flag & add the software path support in as
well (since it's not that much more on top).

[ccameron, 2013-05-31 23:41:54]

sail sent me a patch which added software support -- I've incorporated
that into this patch, and added a command line switch to enable this.

I've added a tracking bug for this work. This isn't part of a specific
sequence anymore (although there is some follow-up bugfixing work
which needs to be done).

Ptal.

[Avi (use Gerrit), 2013-05-31 23:50:55]

tracking bug++

thank you

[sail, 2013-05-31 23:59:14]

lgtm!

https://codereview.chromium.org/16189012/diff/21001/content/browser/renderer_...
File content/browser/renderer_host/compositing_iosurface_layer_mac.mm (right):

https://codereview.chromium.org/16189012/diff/21001/content/browser/renderer_...
content/browser/renderer_host/compositing_iosurface_layer_mac.mm:33:
rect.size.height = [view bounds].size.height;
use NSRectToCGRect?

https://codereview.chromium.org/16189012/diff/21001/content/browser/renderer_...
File content/browser/renderer_host/render_widget_host_view_mac.mm (right):

https://codereview.chromium.org/16189012/diff/21001/content/browser/renderer_...
content/browser/renderer_host/render_widget_host_view_mac.mm:1543: if
(compositing_iosurface_.get() &&
don't need the .get()

https://codereview.chromium.org/16189012/diff/21001/content/browser/renderer_...
content/browser/renderer_host/render_widget_host_view_mac.mm:2447: 
remove new line?

https://codereview.chromium.org/16189012/diff/21001/content/public/common/con...
File content/public/common/content_switches.h (right):

https://codereview.chromium.org/16189012/diff/21001/content/public/common/con...
content/public/common/content_switches.h:253: extern const char
kUseCoreAnimation[];
how about kUserCoreAnimationForRenderWidgetView?
or even better kStopThatAnnoyingFlickering

[Avi (use Gerrit), 2013-05-31 23:59:57]

Random comments on a CL I am otherwise unqualified to review.

https://codereview.chromium.org/16189012/diff/21001/content/browser/renderer_...
File content/browser/renderer_host/render_widget_host_view_mac.h (right):

https://codereview.chromium.org/16189012/diff/21001/content/browser/renderer_...
content/browser/renderer_host/render_widget_host_view_mac.h:403: // Used to test
the CoreAnimation path.
// Whether to use the CoreAnimation path.

https://codereview.chromium.org/16189012/diff/21001/content/browser/renderer_...
File content/browser/renderer_host/render_widget_host_view_mac.mm (right):

https://codereview.chromium.org/16189012/diff/21001/content/browser/renderer_...
content/browser/renderer_host/render_widget_host_view_mac.mm:60: #include
"ui/base/cocoa/animation_utils.h"
alphabetize

https://codereview.chromium.org/16189012/diff/21001/content/browser/renderer_...
content/browser/renderer_host/render_widget_host_view_mac.mm:2447: 
no blank line

[ccameron, 2013-06-01 00:29:45]

Thanks!!

https://codereview.chromium.org/16189012/diff/21001/content/browser/renderer_...
File content/browser/renderer_host/compositing_iosurface_layer_mac.mm (right):

https://codereview.chromium.org/16189012/diff/21001/content/browser/renderer_...
content/browser/renderer_host/compositing_iosurface_layer_mac.mm:33:
rect.size.height = [view bounds].size.height;
On 2013/05/31 23:59:14, sail wrote:
> use NSRectToCGRect?

Done.

https://codereview.chromium.org/16189012/diff/21001/content/browser/renderer_...
File content/browser/renderer_host/render_widget_host_view_mac.h (right):

https://codereview.chromium.org/16189012/diff/21001/content/browser/renderer_...
content/browser/renderer_host/render_widget_host_view_mac.h:403: // Used to test
the CoreAnimation path.
On 2013/05/31 23:59:58, Avi wrote:
> // Whether to use the CoreAnimation path.

Done.

https://codereview.chromium.org/16189012/diff/21001/content/browser/renderer_...
File content/browser/renderer_host/render_widget_host_view_mac.mm (right):

https://codereview.chromium.org/16189012/diff/21001/content/browser/renderer_...
content/browser/renderer_host/render_widget_host_view_mac.mm:60: #include
"ui/base/cocoa/animation_utils.h"
On 2013/05/31 23:59:58, Avi wrote:
> alphabetize

Done.

https://codereview.chromium.org/16189012/diff/21001/content/browser/renderer_...
content/browser/renderer_host/render_widget_host_view_mac.mm:1543: if
(compositing_iosurface_.get() &&
On 2013/05/31 23:59:14, sail wrote:
> don't need the .get()

Removed all instances of compositing_iosurface_.get() from the file (there were
lots...).

https://codereview.chromium.org/16189012/diff/21001/content/browser/renderer_...
content/browser/renderer_host/render_widget_host_view_mac.mm:2447: 
On 2013/05/31 23:59:58, Avi wrote:
> no blank line

Done.

https://codereview.chromium.org/16189012/diff/21001/content/public/common/con...
File content/public/common/content_switches.h (right):

https://codereview.chromium.org/16189012/diff/21001/content/public/common/con...
content/public/common/content_switches.h:253: extern const char
kUseCoreAnimation[];
On 2013/05/31 23:59:14, sail wrote:
> how about kUserCoreAnimationForRenderWidgetView?
> or even better kStopThatAnnoyingFlickering

That' be more clear, but getting to be verbose... I've updated the comment in
content_switches.cc to provide the detail.

[Nico, 2013-06-01 06:15:04]

https://codereview.chromium.org/16189012/diff/29001/content/browser/renderer_...
File content/browser/renderer_host/render_widget_host_view_mac.mm (right):

https://codereview.chromium.org/16189012/diff/29001/content/browser/renderer_...
content/browser/renderer_host/render_widget_host_view_mac.mm:3515:
inContext:context];
Did you benchmark what this does to scrolling perf on software-rendered pages?
From what I understand, this draws the backing store one additional time.

From some earlier (pre-RAF) scroll perf bug: """I've been testing this by
running the following snippet of javascript, then measuring the resulting 
framerate in Quartz Debug:

javascript:setInterval(function(){ scrollBy(0,1) }, 1000/60)"""

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

https://codereview.chromium.org/16189012/diff/29001/content/browser/renderer_...
File content/browser/renderer_host/compositing_iosurface_layer_mac.h (right):

https://codereview.chromium.org/16189012/diff/29001/content/browser/renderer_...
content/browser/renderer_host/compositing_iosurface_layer_mac.h:31: //
displays). This will re-allocate the context if need be, and returns whether
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:58]

https://codereview.chromium.org/16189012/diff/29001/content/browser/renderer_...
File content/browser/renderer_host/compositing_iosurface_layer_mac.h (right):

https://codereview.chromium.org/16189012/diff/29001/content/browser/renderer_...
content/browser/renderer_host/compositing_iosurface_layer_mac.h:31: //
displays). This will re-allocate the context if need be, and returns whether
On 2013/06/03 22:05:01, kbr wrote:
> 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.

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]

lgtm

https://codereview.chromium.org/16189012/diff/29001/content/browser/renderer_...
File content/browser/renderer_host/compositing_iosurface_layer_mac.h (right):

https://codereview.chromium.org/16189012/diff/29001/content/browser/renderer_...
content/browser/renderer_host/compositing_iosurface_layer_mac.h:31: //
displays). This will re-allocate the context if need be, and returns whether
On 2013/06/03 22:14:59, ccameron1 wrote:
> On 2013/06/03 22:05:01, kbr wrote:
> > 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.
> 
> 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.

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.

[ccameron, 2013-06-03 22:54:09]

https://codereview.chromium.org/16189012/diff/29001/content/browser/renderer_...
File content/browser/renderer_host/render_widget_host_view_mac.mm (right):

https://codereview.chromium.org/16189012/diff/29001/content/browser/renderer_...
content/browser/renderer_host/render_widget_host_view_mac.mm:3515:
inContext:context];
On 2013/06/01 06:15:05, Nico wrote:
> Did you benchmark what this does to scrolling perf on software-rendered pages?
> From what I understand, this draws the backing store one additional time.
> 
> From some earlier (pre-RAF) scroll perf bug: """I've been testing this by
> running the following snippet of javascript, then measuring the resulting 
> framerate in Quartz Debug:
> 
> javascript:setInterval(function(){ scrollBy(0,1) }, 1000/60)"""

I tested this with PosterCircle and with the scrollBy test, and Quartz Debug
reports a solid 60fps.

[ccameron, 2013-06-04 18:31:18]

thakis, do you want to review this, or are you okay with kbr+sail?

[Nico, 2013-06-05 00:13:07]

If kbr and sail are happy, I'm mostly happy too.

Some more minor comments below; I'd like some more perf data.

Also, thoughts on testing?

https://codereview.chromium.org/16189012/diff/29001/content/browser/renderer_...
File content/browser/renderer_host/compositing_iosurface_layer_mac.mm (right):

https://codereview.chromium.org/16189012/diff/29001/content/browser/renderer_...
content/browser/renderer_host/compositing_iosurface_layer_mac.mm:18: @end
Consider putting this in base/mac/sdk_forward_declarations.h

https://codereview.chromium.org/16189012/diff/29001/content/browser/renderer_...
File content/browser/renderer_host/render_widget_host_view_mac.mm (right):

https://codereview.chromium.org/16189012/diff/29001/content/browser/renderer_...
content/browser/renderer_host/render_widget_host_view_mac.mm:87: @end
(if you do that, include that file instead of this)

https://codereview.chromium.org/16189012/diff/29001/content/browser/renderer_...
content/browser/renderer_host/render_widget_host_view_mac.mm:1694: [self
setLayer:layer];
It looks like you never remove this. Is CA smart about not drawing completely
hidden layers, or will this keep a tab-sized white layer around per tab and draw
this below the actual layer we care about on every frame?

https://codereview.chromium.org/16189012/diff/29001/content/browser/renderer_...
content/browser/renderer_host/render_widget_host_view_mac.mm:2458: NSRect
nsDirtyRect = NSMakeRect(dirtyRect.origin.x,
Use NSRectFromCGRect() instead

https://codereview.chromium.org/16189012/diff/29001/content/browser/renderer_...
content/browser/renderer_host/render_widget_host_view_mac.mm:3515:
inContext:context];
On 2013/06/03 22:54:09, ccameron1 wrote:
> On 2013/06/01 06:15:05, Nico wrote:
> > Did you benchmark what this does to scrolling perf on software-rendered
pages?
> > From what I understand, this draws the backing store one additional time.
> > 
> > From some earlier (pre-RAF) scroll perf bug: """I've been testing this by
> > running the following snippet of javascript, then measuring the resulting 
> > framerate in Quartz Debug:
> > 
> > javascript:setInterval(function(){ scrollBy(0,1) }, 1000/60)"""
> 
> I tested this with PosterCircle and with the scrollBy test, and Quartz Debug
> reports a solid 60fps.
> 

Any difference in %cpu? (between CA path and previous path; both on hardware and
software pages)

[ccameron, 2013-06-05 19:24:13]

WRT testing and performance tuning, this path still has some work that needs to
be done (there is visual corruption on the bookmark bar, among other things).

https://codereview.chromium.org/16189012/diff/29001/content/browser/renderer_...
File content/browser/renderer_host/compositing_iosurface_layer_mac.mm (right):

https://codereview.chromium.org/16189012/diff/29001/content/browser/renderer_...
content/browser/renderer_host/compositing_iosurface_layer_mac.mm:18: @end
On 2013/06/05 00:13:07, Nico wrote:
> Consider putting this in base/mac/sdk_forward_declarations.h

Done.

https://codereview.chromium.org/16189012/diff/29001/content/browser/renderer_...
File content/browser/renderer_host/render_widget_host_view_mac.mm (right):

https://codereview.chromium.org/16189012/diff/29001/content/browser/renderer_...
content/browser/renderer_host/render_widget_host_view_mac.mm:87: @end
On 2013/06/05 00:13:07, Nico wrote:
> (if you do that, include that file instead of this)

Nice, and got to delete some redundant code below.

https://codereview.chromium.org/16189012/diff/29001/content/browser/renderer_...
content/browser/renderer_host/render_widget_host_view_mac.mm:1694: [self
setLayer:layer];
On 2013/06/05 00:13:07, Nico wrote:
> It looks like you never remove this. Is CA smart about not drawing completely
> hidden layers, or will this keep a tab-sized white layer around per tab and
draw
> this below the actual layer we care about on every frame?

Good point. My next patch will allow us to dynamically switch to using CA (e.g,
when the find bar comes down), so I'll make sure we don't do any extra drawing
there.

Also of note is that we just put the compositing CALayer on top of the software
CALayer, so I'll have to check this for both of these.

https://codereview.chromium.org/16189012/diff/29001/content/browser/renderer_...
content/browser/renderer_host/render_widget_host_view_mac.mm:2458: NSRect
nsDirtyRect = NSMakeRect(dirtyRect.origin.x,
On 2013/06/05 00:13:07, Nico wrote:
> Use NSRectFromCGRect() instead

Done.

https://codereview.chromium.org/16189012/diff/29001/content/browser/renderer_...
content/browser/renderer_host/render_widget_host_view_mac.mm:3515:
inContext:context];
On 2013/06/05 00:13:07, Nico wrote:
> On 2013/06/03 22:54:09, ccameron1 wrote:
> > On 2013/06/01 06:15:05, Nico wrote:
> > > Did you benchmark what this does to scrolling perf on software-rendered
> pages?
> > > From what I understand, this draws the backing store one additional time.
> > > 
> > > From some earlier (pre-RAF) scroll perf bug: """I've been testing this by
> > > running the following snippet of javascript, then measuring the resulting 
> > > framerate in Quartz Debug:
> > > 
> > > javascript:setInterval(function(){ scrollBy(0,1) }, 1000/60)"""
> > 
> > I tested this with PosterCircle and with the scrollBy test, and Quartz Debug
> > reports a solid 60fps.
> > 
> 
> Any difference in %cpu? (between CA path and previous path; both on hardware
and
> software pages)

CA has higher CPU usage both with and without the GPU enabled (on poster
circle). It was 3.5%->5% for hardware and 7%->10% for software. I haven't tried
removing the extra background layers yet, to see if that changes the behavior.

[ccameron, 2013-06-05 19:32:39]

Adding piman for content/ OWNER stamp.

And I'll need thakis for base/mac OWNER stamp.

[Nico, 2013-06-06 01:22:48]

lgtm, thanks

Can you put the

"""CA has higher CPU usage both with and without the GPU enabled (on poster
circle). It was 3.5%->5% for hardware and 7%->10% for software. We're working on
improving this."""

in the CL description please? (or something similar)

[piman, 2013-06-06 03:27:17]

lgtm

[commit-bot: I haz the power, 2013-06-07 02:11:13]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ccameron@chromium.org/16189012/45007

[commit-bot: I haz the power, 2013-06-07 02:11:17]

Failed to apply patch for
content/browser/renderer_host/compositing_iosurface_mac.mm:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  patching file content/browser/renderer_host/compositing_iosurface_mac.mm
  Hunk #1 FAILED at 18.
  Hunk #2 succeeded at 239 (offset 1 line).
  Hunk #3 succeeded at 384 with fuzz 2 (offset 3 lines).
  Hunk #4 succeeded at 403 (offset 4 lines).
  Hunk #5 succeeded at 540 with fuzz 2 (offset 4 lines).
  Hunk #6 succeeded at 555 (offset 8 lines).
  1 out of 6 hunks FAILED -- saving rejects to file
content/browser/renderer_host/compositing_iosurface_mac.mm.rej

Patch:       content/browser/renderer_host/compositing_iosurface_mac.mm
Index: content/browser/renderer_host/compositing_iosurface_mac.mm
diff --git a/content/browser/renderer_host/compositing_iosurface_mac.mm
b/content/browser/renderer_host/compositing_iosurface_mac.mm
index
24f49913950cb6508670ed5d3cf9c4efab6db476..3a9d4d7878219373394e06ae6432a57794a8404d
100644
--- a/content/browser/renderer_host/compositing_iosurface_mac.mm
+++ b/content/browser/renderer_host/compositing_iosurface_mac.mm
@@ -18,6 +18,7 @@
 #include "content/browser/renderer_host/compositing_iosurface_context_mac.h"
 #include
"content/browser/renderer_host/compositing_iosurface_shader_programs_mac.h"
 #include
"content/browser/renderer_host/compositing_iosurface_transformer_mac.h"
+#include "content/browser/renderer_host/render_widget_host_view_mac.h"
 #include "content/common/content_constants_internal.h"
 #include "content/port/browser/render_widget_host_view_frame_subscriber.h"
 #include "gpu/command_buffer/service/gpu_switches.h"
@@ -238,25 +239,36 @@ void
CompositingIOSurfaceMac::CopyContext::PrepareForAsynchronousReadback() {
 // static
 CompositingIOSurfaceMac* CompositingIOSurfaceMac::Create(int window_number) {
   TRACE_EVENT0("browser", "CompositingIOSurfaceMac::Create");
+
+  scoped_refptr<CompositingIOSurfaceContext> context =
+      CompositingIOSurfaceContext::Get(window_number);
+  if (!context) {
+    LOG(WARNING) << "Failed to create context for IOSurface";
+    return NULL;
+  }
+
+  return Create(context);
+}
+
+CompositingIOSurfaceMac* CompositingIOSurfaceMac::Create(
+    const scoped_refptr<CompositingIOSurfaceContext>& context) {
   IOSurfaceSupport* io_surface_support = IOSurfaceSupport::Initialize();
   if (!io_surface_support) {
     LOG(WARNING) << "No IOSurface support";
     return NULL;
   }
 
-  scoped_refptr<CompositingIOSurfaceContext> context =
-      CompositingIOSurfaceContext::Get(window_number);
-
   return new CompositingIOSurfaceMac(io_surface_support,
                                      context);
 }
 
 CompositingIOSurfaceMac::CompositingIOSurfaceMac(
     IOSurfaceSupport* io_surface_support,
-    scoped_refptr<CompositingIOSurfaceContext> context)
+    const scoped_refptr<CompositingIOSurfaceContext>& context)
     : io_surface_support_(io_surface_support),
       context_(context),
       io_surface_handle_(0),
+      scale_factor_(1.f),
       texture_(0),
       finish_copy_timer_(
           FROM_HERE,
@@ -370,8 +382,9 @@ void CompositingIOSurfaceMac::SetIOSurface(uint64
io_surface_handle,
                                            const gfx::Size& size,
                                            float scale_factor) {
   pixel_io_surface_size_ = size;
+  scale_factor_ = scale_factor;
   dip_io_surface_size_ = gfx::ToFlooredSize(
-      gfx::ScaleSize(pixel_io_surface_size_, 1.0 / scale_factor));
+      gfx::ScaleSize(pixel_io_surface_size_, 1.0 / scale_factor_));
   CGLSetCurrentContext(context_->cgl_context());
   MapIOSurfaceToTexture(io_surface_handle);
   CGLSetCurrentContext(0);
@@ -387,29 +400,44 @@ int CompositingIOSurfaceMac::GetRendererID() {
 }
 
 void CompositingIOSurfaceMac::DrawIOSurface(
-    NSView* view,
-    float scale_factor,
-    int window_number,
-    SurfaceOrder surface_order,
-    RenderWidgetHostViewFrameSubscriber* frame_subscriber) {
+    RenderWidgetHostViewMac* render_widget_host_view) {
+  DCHECK(!render_widget_host_view->use_core_animation_);
 
-  if (display_link_ == NULL)
-    SetupCVDisplayLink();
+  NSView* view = render_widget_host_view->cocoa_view();
+  content::CompositingIOSurfaceMac::SurfaceOrder surface_order =
+     render_widget_host_view->allow_overlapping_views_
+     ? content::CompositingIOSurfaceMac::SURFACE_ORDER_BELOW_WINDOW
+     : content::CompositingIOSurfaceMac::SURFACE_ORDER_ABOVE_WINDOW;
 
-  SwitchToContextOnNewWindow(view, window_number);
+  SwitchToContextOnNewWindow(view, render_widget_host_view->window_number());
   SetSurfaceOrder(context_->nsgl_context(), surface_order);
 
   CGLSetCurrentContext(context_->cgl_context());
+  [context_->nsgl_context() setView:view];
 
-  bool has_io_surface = MapIOSurfaceToTexture(io_surface_handle_);
+  gfx::Size window_size(NSSizeToCGSize([view frame].size));
+
+  DrawIOSurface(
+      window_size,
+      render_widget_host_view->scale_factor(),
+      render_widget_host_view->frame_subscriber(),
+      false);
+}
+
+void CompositingIOSurfaceMac::DrawIOSurface(
+    const gfx::Size& window_size,
+    float window_scale_factor,
+    RenderWidgetHostViewFrameSubscriber* frame_subscriber,
+    bool using_core_animation) {
+  if (display_link_ == NULL)
+    SetupCVDisplayLink();
 
+  bool has_io_surface = MapIOSurfaceToTexture(io_surface_handle_);
   TRACE_EVENT1("browser", "CompositingIOSurfaceMac::DrawIOSurface",
                "has_io_surface", has_io_surface);
 
-  [context_->nsgl_context() setView:view];
-  gfx::Size window_size(NSSizeToCGSize([view frame].size));
   gfx::Size pixel_window_size = gfx::ToFlooredSize(
-      gfx::ScaleSize(window_size, scale_factor));
+      gfx::ScaleSize(window_size, window_scale_factor));
   glViewport(0, 0, pixel_window_size.width(), pixel_window_size.height());
 
   SurfaceQuad quad;
@@ -509,7 +537,8 @@ void CompositingIOSurfaceMac::DrawIOSurface(
     }
   }
 
-  CGLFlushDrawable(context_->cgl_context());
+  if (!using_core_animation)
+    CGLFlushDrawable(context_->cgl_context());
 
   // For latency_tests.cc:
   UNSHIPPED_TRACE_EVENT_INSTANT0("test_gpu", "CompositorSwapBuffersComplete",
@@ -519,7 +548,8 @@ void CompositingIOSurfaceMac::DrawIOSurface(
   std::vector<base::Closure> copy_done_callbacks;
   FinishAllCopiesWithinContext(&copy_done_callbacks);
 
-  CGLSetCurrentContext(0);
+  if (!using_core_animation)
+    CGLSetCurrentContext(0);
 
   if (!copy_done_callback.is_null())
     copy_done_callbacks.push_back(copy_done_callback);

[commit-bot: I haz the power, 2013-06-07 02:43:05]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ccameron@chromium.org/16189012/67001

[commit-bot: I haz the power, 2013-06-07 08:10:44]

Retried try job too often on win_rel for step(s) nacl_integration
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...

[commit-bot: I haz the power, 2013-06-07 15:19:45]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ccameron@chromium.org/16189012/67001

[commit-bot: I haz the power, 2013-06-07 15:20:19]

Change committed as 204841