Make --enable-delegated-renderer show stuff on Mac

Make --enable-delegated-renderer show stuff on Mac

With this patch, pixels appear on screen and tab capture works.

Add a OnNativeSurfaceBuffersSwapped mechanism to display
an IOSurface to an NSView. This is wired up to the existing
CompositingIOSurfaceMac. In a future refactoring, something
much more light-weight than CompositingIOSurfaceMac will
be used (CompositingIOSurfaceMac has capture code, etc, in
it).

Add a DelegatedFrameHost to RenderWidgetHostViewMac, and
hookup the DelegatedFrameHostClient implementation. Create
the DelegatedFrameHost when a delegated frame is received, and
use its existence to determine which mode is active.

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

[ccameron, 2014-05-06 00:20:32]

ptal

https://codereview.chromium.org/267073003/diff/20001/cc/resources/resource_pr...
File cc/resources/resource_provider.cc (left):

https://codereview.chromium.org/267073003/diff/20001/cc/resources/resource_pr...
cc/resources/resource_provider.cc:1615: DCHECK_EQ(source->wrap_mode,
GL_CLAMP_TO_EDGE);
I added this check when implementing wrapping, to make sure nobody tried to use
it in a ÜC without some testing first -- this works fine.

https://codereview.chromium.org/267073003/diff/20001/content/browser/composit...
File content/browser/compositor/delegated_frame_host.h (right):

https://codereview.chromium.org/267073003/diff/20001/content/browser/composit...
content/browser/compositor/delegated_frame_host.h:261: YES_CAN_LOCK,
Objective C uses YES/NO for booleans, so this had to change.

https://codereview.chromium.org/267073003/diff/20001/content/browser/gpu/gpu_...
File content/browser/gpu/gpu_process_host.cc (right):

https://codereview.chromium.org/267073003/diff/20001/content/browser/gpu/gpu_...
content/browser/gpu/gpu_process_host.cc:806:
RenderWidgetHelper::OnNativeSurfaceBuffersSwapped(params);
We may want to move this to a place higher up in the layer cake -- this
currently leans on the existing CompositingIOSurface code to display (which has
all sorts of stuff hanging around for tab capture). We can get away with
something much more light-weight now that tab-capture goes through the ÜC
mechanisms.

[piman, 2014-05-06 00:59:00]

A few things. I understand this is work in progress, but I think putting things
in the right places would help.

https://codereview.chromium.org/267073003/diff/20001/content/browser/gpu/gpu_...
File content/browser/gpu/gpu_process_host.cc (right):

https://codereview.chromium.org/267073003/diff/20001/content/browser/gpu/gpu_...
content/browser/gpu/gpu_process_host.cc:806:
RenderWidgetHelper::OnNativeSurfaceBuffersSwapped(params);
On 2014/05/06 00:20:32, ccameron1 wrote:
> We may want to move this to a place higher up in the layer cake -- this
> currently leans on the existing CompositingIOSurface code to display (which
has
> all sorts of stuff hanging around for tab capture). We can get away with
> something much more light-weight now that tab-capture goes through the ÜC
> mechanisms.

Definitely not for this patch, but I'm hoping we can rework things to create the
IOSurface on the browser side, managed by a mac-specific OutputSurface, using it
as an explicit texture/FBO via the existing TexImageIOSurface2DCHROMIUM, and
then completely remove the AcceleratedSurfaceBuffersSwapped IPCs.

https://codereview.chromium.org/267073003/diff/20001/content/browser/renderer...
File content/browser/renderer_host/render_widget_host_view_mac.mm (right):

https://codereview.chromium.org/267073003/diff/20001/content/browser/renderer...
content/browser/renderer_host/render_widget_host_view_mac.mm:427: void
RenderWidgetHelper::OnNativeSurfaceBuffersSwapped(
nit: move to render_widget_helper.cc

https://codereview.chromium.org/267073003/diff/20001/content/browser/renderer...
content/browser/renderer_host/render_widget_host_view_mac.mm:442:
CAUSE_FOR_GPU_LAUNCH_NO_LAUNCH);
This is coming from  GpuProcessHost::OnAcceleratedSurfaceBuffersSwapped, so
maybe you can pass |this| from there?

https://codereview.chromium.org/267073003/diff/20001/content/browser/renderer...
content/browser/renderer_host/render_widget_host_view_mac.mm:458:
GpuSurfaceTracker::Get()->AcquireNativeWidget(params.surface_id);
Because of races, this could be kNullAcceleratedWidget (e.g. if a frame is in
flight during destruction).

https://codereview.chromium.org/267073003/diff/20001/content/browser/renderer...
content/browser/renderer_host/render_widget_host_view_mac.mm:1939:
compositor_initializer_;
Can we move this to BrowserMainLoop? That is where we're doing Aura-specific
initialization, it seems like it'd be a good place to do this (possibly only if
--enable-delegated-rendering is set, if you're concerned about side effects).

https://codereview.chromium.org/267073003/diff/20001/content/browser/renderer...
content/browser/renderer_host/render_widget_host_view_mac.mm:1959:
root_layer_->SetBounds(gfx::Rect(0, 0, size.width(), size.height()));
I think both of these should be done when the RWHVMac changes size/DSF, not when
the frame changes size.

ui::Layer has some code to handle mismatch between frame size and layer size.
Also with DSF. Think transient states when moving from a low-DPI to a high-DPI
screen.

https://codereview.chromium.org/267073003/diff/20001/content/browser/renderer...
content/browser/renderer_host/render_widget_host_view_mac.mm:1974:
AddPendingLatencyInfo(frame->metadata.latency_info);
you'll want to do this in either case.

[ccameron, 2014-05-06 17:15:55]

Did most of the suggestions -- not sure what to do about where to put the
OnNativeSurfaceBuffersSwapped method (needs to be a .mm somewhere). LMK if you
have ideas (I could add a RWhelper_mac.mm for just-this).

https://codereview.chromium.org/267073003/diff/20001/content/browser/renderer...
File content/browser/renderer_host/render_widget_host_view_mac.mm (right):

https://codereview.chromium.org/267073003/diff/20001/content/browser/renderer...
content/browser/renderer_host/render_widget_host_view_mac.mm:427: void
RenderWidgetHelper::OnNativeSurfaceBuffersSwapped(
On 2014/05/06 00:59:01, piman wrote:
> nit: move to render_widget_helper.cc

This need to (at some point), bottom out in Objective C call, which can't be
done from a .cc.

For similar reasons, the other option of making it an RWHVMac static method and
calling that here wasn't an option (can't include rwhv_mac.h because of its
Objective C isms).

Other ideas of how to go about it?

https://codereview.chromium.org/267073003/diff/20001/content/browser/renderer...
content/browser/renderer_host/render_widget_host_view_mac.mm:442:
CAUSE_FOR_GPU_LAUNCH_NO_LAUNCH);
On 2014/05/06 00:59:01, piman wrote:
> This is coming from  GpuProcessHost::OnAcceleratedSurfaceBuffersSwapped, so
> maybe you can pass |this| from there?

Good idea. Done.

https://codereview.chromium.org/267073003/diff/20001/content/browser/renderer...
content/browser/renderer_host/render_widget_host_view_mac.mm:458:
GpuSurfaceTracker::Get()->AcquireNativeWidget(params.surface_id);
On 2014/05/06 00:59:01, piman wrote:
> Because of races, this could be kNullAcceleratedWidget (e.g. if a frame is in
> flight during destruction).

Calling a method on a NULL object in Objective C is a no-op, so there's a
convention of doing
  [x meth]
instead of
  if (x)
    [x meth]
to be more concise.

https://codereview.chromium.org/267073003/diff/20001/content/browser/renderer...
content/browser/renderer_host/render_widget_host_view_mac.mm:1939:
compositor_initializer_;
On 2014/05/06 00:59:01, piman wrote:
> Can we move this to BrowserMainLoop? That is where we're doing Aura-specific
> initialization, it seems like it'd be a good place to do this (possibly only
if
> --enable-delegated-rendering is set, if you're concerned about side effects).

Done.

https://codereview.chromium.org/267073003/diff/20001/content/browser/renderer...
content/browser/renderer_host/render_widget_host_view_mac.mm:1959:
root_layer_->SetBounds(gfx::Rect(0, 0, size.width(), size.height()));
On 2014/05/06 00:59:01, piman wrote:
> I think both of these should be done when the RWHVMac changes size/DSF, not
when
> the frame changes size.
> 
> ui::Layer has some code to handle mismatch between frame size and layer size.
> Also with DSF. Think transient states when moving from a low-DPI to a high-DPI
> screen.

I've found it best to resize everything to match the frame coming in (including
the dpi and CALayer size) -- CoreAnimation will display a lodpi layer correctly
on a hidpi screen (and vice-versa).

So, I suspect that this will be the place where I'll want to update sizes --
that way, the next frame that I get from the ui::Compositor will be the size and
DPI of the delegated frame.

This way I let CoreAnimation handle the transient states, and minimize the
number of ui::Compositor commits that I do (I try to make them 1:1 with
delegated frames).

https://codereview.chromium.org/267073003/diff/20001/content/browser/renderer...
content/browser/renderer_host/render_widget_host_view_mac.mm:1974:
AddPendingLatencyInfo(frame->metadata.latency_info);
On 2014/05/06 00:59:01, piman wrote:
> you'll want to do this in either case.

The DelegatedFrameHost tracks the latency_info for us (in particular, makes it a
compositor on-commit callback).

I should probably move the latency_info tracking here into SoftwareFrameManager,
to better match what DelegatedFrameHost does.

[piman, 2014-05-06 19:58:08]

https://codereview.chromium.org/267073003/diff/20001/content/browser/renderer...
File content/browser/renderer_host/render_widget_host_view_mac.mm (right):

https://codereview.chromium.org/267073003/diff/20001/content/browser/renderer...
content/browser/renderer_host/render_widget_host_view_mac.mm:427: void
RenderWidgetHelper::OnNativeSurfaceBuffersSwapped(
On 2014/05/06 17:15:56, ccameron1 wrote:
> On 2014/05/06 00:59:01, piman wrote:
> > nit: move to render_widget_helper.cc
> 
> This need to (at some point), bottom out in Objective C call, which can't be
> done from a .cc.
> 
> For similar reasons, the other option of making it an RWHVMac static method
and
> calling that here wasn't an option (can't include rwhv_mac.h because of its
> Objective C isms).
> 
> Other ideas of how to go about it?

I guess render_widget_helper_mac.mm is probably the best.

https://codereview.chromium.org/267073003/diff/20001/content/browser/renderer...
content/browser/renderer_host/render_widget_host_view_mac.mm:458:
GpuSurfaceTracker::Get()->AcquireNativeWidget(params.surface_id);
On 2014/05/06 17:15:56, ccameron1 wrote:
> On 2014/05/06 00:59:01, piman wrote:
> > Because of races, this could be kNullAcceleratedWidget (e.g. if a frame is
in
> > flight during destruction).
> 
> Calling a method on a NULL object in Objective C is a no-op, so there's a
> convention of doing
>   [x meth]
> instead of
>   if (x)
>     [x meth]
> to be more concise.

Ok, thanks.

https://codereview.chromium.org/267073003/diff/20001/content/browser/renderer...
content/browser/renderer_host/render_widget_host_view_mac.mm:1959:
root_layer_->SetBounds(gfx::Rect(0, 0, size.width(), size.height()));
On 2014/05/06 17:15:56, ccameron1 wrote:
> On 2014/05/06 00:59:01, piman wrote:
> > I think both of these should be done when the RWHVMac changes size/DSF, not
> when
> > the frame changes size.
> > 
> > ui::Layer has some code to handle mismatch between frame size and layer
size.
> > Also with DSF. Think transient states when moving from a low-DPI to a
high-DPI
> > screen.
> 
> I've found it best to resize everything to match the frame coming in
(including
> the dpi and CALayer size) -- CoreAnimation will display a lodpi layer
correctly
> on a hidpi screen (and vice-versa).
> 
> So, I suspect that this will be the place where I'll want to update sizes --
> that way, the next frame that I get from the ui::Compositor will be the size
and
> DPI of the delegated frame.
> 
> This way I let CoreAnimation handle the transient states, and minimize the
> number of ui::Compositor commits that I do (I try to make them 1:1 with
> delegated frames).

What about the non-CA path?

I guess what you suggest is possible, but it is a deviation from Aura...

https://codereview.chromium.org/267073003/diff/20001/content/browser/renderer...
content/browser/renderer_host/render_widget_host_view_mac.mm:1974:
AddPendingLatencyInfo(frame->metadata.latency_info);
On 2014/05/06 17:15:56, ccameron1 wrote:
> On 2014/05/06 00:59:01, piman wrote:
> > you'll want to do this in either case.
> 
> The DelegatedFrameHost tracks the latency_info for us (in particular, makes it
a
> compositor on-commit callback).
> 
> I should probably move the latency_info tracking here into
SoftwareFrameManager,
> to better match what DelegatedFrameHost does.

Ok.

[piman, 2014-05-06 20:02:53]

https://codereview.chromium.org/267073003/diff/40001/content/browser/renderer...
File content/browser/renderer_host/render_widget_host_view_mac.mm (right):

https://codereview.chromium.org/267073003/diff/40001/content/browser/renderer...
content/browser/renderer_host/render_widget_host_view_mac.mm:440:
base::Bind(&OnNativeSurfaceBuffersSwapped, gpu_process_host, params));
It kinda calls for having a different function for the UI thread.
OnNativeSurfaceBuffersSwappedOnIO vs OnNativeSurfaceBuffersSwappedOnUI

That way we can DCHECK the thread and verify that the right thing is done (e.g.
calling OnNativeSurfaceBuffersSwapped directly on the UI thread would miss a
critical part).

[ccameron, 2014-05-06 20:38:59]

https://codereview.chromium.org/267073003/diff/20001/content/browser/renderer...
File content/browser/renderer_host/render_widget_host_view_mac.mm (right):

https://codereview.chromium.org/267073003/diff/20001/content/browser/renderer...
content/browser/renderer_host/render_widget_host_view_mac.mm:427: void
RenderWidgetHelper::OnNativeSurfaceBuffersSwapped(
On 2014/05/06 19:58:09, piman wrote:
> On 2014/05/06 17:15:56, ccameron1 wrote:
> > On 2014/05/06 00:59:01, piman wrote:
> > > nit: move to render_widget_helper.cc
> > 
> > This need to (at some point), bottom out in Objective C call, which can't be
> > done from a .cc.
> > 
> > For similar reasons, the other option of making it an RWHVMac static method
> and
> > calling that here wasn't an option (can't include rwhv_mac.h because of its
> > Objective C isms).
> > 
> > Other ideas of how to go about it?
> 
> I guess render_widget_helper_mac.mm is probably the best.

Done.

https://codereview.chromium.org/267073003/diff/20001/content/browser/renderer...
content/browser/renderer_host/render_widget_host_view_mac.mm:1959:
root_layer_->SetBounds(gfx::Rect(0, 0, size.width(), size.height()));
On 2014/05/06 19:58:09, piman wrote:
> On 2014/05/06 17:15:56, ccameron1 wrote:
> > On 2014/05/06 00:59:01, piman wrote:
> > > I think both of these should be done when the RWHVMac changes size/DSF,
not
> > when
> > > the frame changes size.
> > > 
> > > ui::Layer has some code to handle mismatch between frame size and layer
> size.
> > > Also with DSF. Think transient states when moving from a low-DPI to a
> high-DPI
> > > screen.
> > 
> > I've found it best to resize everything to match the frame coming in
> (including
> > the dpi and CALayer size) -- CoreAnimation will display a lodpi layer
> correctly
> > on a hidpi screen (and vice-versa).
> > 
> > So, I suspect that this will be the place where I'll want to update sizes --
> > that way, the next frame that I get from the ui::Compositor will be the size
> and
> > DPI of the delegated frame.
> > 
> > This way I let CoreAnimation handle the transient states, and minimize the
> > number of ui::Compositor commits that I do (I try to make them 1:1 with
> > delegated frames).
> 
> What about the non-CA path?

non-CA path will be deleted soon (grin).

> I guess what you suggest is possible, but it is a deviation from Aura...

There's a lot which is iffy about this area (the thing that I mentioned earlier
about transforms not getting updated -- the issues I'm having with window
resize). I suspect I'll have to clean up a few layers here.

https://codereview.chromium.org/267073003/diff/40001/content/browser/renderer...
File content/browser/renderer_host/render_widget_host_view_mac.mm (right):

https://codereview.chromium.org/267073003/diff/40001/content/browser/renderer...
content/browser/renderer_host/render_widget_host_view_mac.mm:440:
base::Bind(&OnNativeSurfaceBuffersSwapped, gpu_process_host, params));
On 2014/05/06 20:02:54, piman wrote:
> It kinda calls for having a different function for the UI thread.
> OnNativeSurfaceBuffersSwappedOnIO vs OnNativeSurfaceBuffersSwappedOnUI
> 
> That way we can DCHECK the thread and verify that the right thing is done
(e.g.
> calling OnNativeSurfaceBuffersSwapped directly on the UI thread would miss a
> critical part).

Done.

[ccameron, 2014-05-06 23:39:09]

I dug a bit deeper into the DPI issues I was having, and we'll probably have to
discuss how the ui::Compositor should work (it doesn't actually set its
LayerTreeHost's DeviceScaleFactor, at any point, which isn't the way that I
planned to use it).

I also updated the patch work with browser resizing, which required more odd
behaviors to avoid having transform matrices turn into NaNs.

I think the next few patches will need to be cleanup of these (& other) issues.

[Ken Russell (switch to Gerrit), 2014-05-06 23:48:17]

Looks like great progress. I don't have any substantive comments.

[piman, 2014-05-07 00:32:54]

https://codereview.chromium.org/267073003/diff/100001/content/browser/rendere...
File content/browser/renderer_host/render_widget_host_view_mac.mm (right):

https://codereview.chromium.org/267073003/diff/100001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_view_mac.mm:1882:
compositor_->SetRootLayer(nil);
nit: nil? NULL?

https://codereview.chromium.org/267073003/diff/100001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_view_mac.mm:1893: // composited
frame that is recieved having the right scale factor. Fix
nit: received

https://codereview.chromium.org/267073003/diff/100001/content/content_browser...
File content/content_browser.gypi (right):

https://codereview.chromium.org/267073003/diff/100001/content/content_browser...
content/content_browser.gypi:1091:
'browser/renderer_host/render_widget_helper_mac.mm',
This file isn't in the latest patch.

[ccameron, 2014-05-07 00:37:47]

https://codereview.chromium.org/267073003/diff/100001/content/browser/rendere...
File content/browser/renderer_host/render_widget_host_view_mac.mm (right):

https://codereview.chromium.org/267073003/diff/100001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_view_mac.mm:1882:
compositor_->SetRootLayer(nil);
On 2014/05/07 00:32:55, piman wrote:
> nit: nil? NULL?

Changed to NULL (oops - nil is for Objective C ids, this is a class).

https://codereview.chromium.org/267073003/diff/100001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_view_mac.mm:1893: // composited
frame that is recieved having the right scale factor. Fix
On 2014/05/07 00:32:55, piman wrote:
> nit: received

Done.

https://codereview.chromium.org/267073003/diff/100001/content/content_browser...
File content/content_browser.gypi (right):

https://codereview.chromium.org/267073003/diff/100001/content/content_browser...
content/content_browser.gypi:1091:
'browser/renderer_host/render_widget_helper_mac.mm',
On 2014/05/07 00:32:55, piman wrote:
> This file isn't in the latest patch.

Added

[ccameron, 2014-05-08 16:55:01]

ping

[piman, 2014-05-08 18:16:53]

lgtm

[ccameron, 2014-05-08 18:52:02]

Thanks!

[ccameron, 2014-05-08 18:52:07]

The CQ bit was checked by ccameron@chromium.org

[commit-bot: I haz the power, 2014-05-08 18:54:26]

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

[commit-bot: I haz the power, 2014-05-08 21:59:01]

FYI, CQ is re-trying this CL (attempt #1).
Please consider checking whether the failures are real,
and report flakes to chrome-troopers@google.com.
The failing builders are:
  android_aosp on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/android_aosp/builds/7...)
  android_chromium_gn_compile_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/android_chromium_gn_c...)
  android_clang_dbg on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/android_clang_dbg/bui...)
  android_dbg on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/android_dbg/builds/18...)
  chromium_presubmit on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/chromium_presubmit/bu...)
  ios_dbg_simulator on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/ios_dbg_simulator/bui...)
  ios_rel_device on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/ios_rel_device/builds...)
  ios_rel_device_ninja on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/ios_rel_device_ninja/...)
  linux_chromium_chromeos_clang_dbg on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_chrome...)
  linux_chromium_chromeos_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_chrome...)
  linux_chromium_clang_dbg on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_clang_...)
  linux_chromium_gn_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_gn_rel...)
  linux_chromium_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_rel/bu...)
  mac_chromium_compile_dbg on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/mac_chromium_compile_...)
  mac_chromium_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/mac_chromium_rel/buil...)
  win_chromium_compile_dbg on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_compile_...)
  win_chromium_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_rel/buil...)
  win_chromium_x64_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_x64_rel/...)

[commit-bot: I haz the power, 2014-05-08 22:07:02]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-05-08 22:07:03]

Try jobs failed on following builders:
  android_chromium_gn_compile_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/android_chromium_gn_c...)
  ios_dbg_simulator on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/ios_dbg_simulator/bui...)
  ios_rel_device on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/ios_rel_device/builds...)
  ios_rel_device_ninja on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/ios_rel_device_ninja/...)
  linux_chromium_chromeos_clang_dbg on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_chrome...)
  linux_chromium_chromeos_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_chrome...)
  linux_chromium_clang_dbg on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_clang_...)
  linux_chromium_gn_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_gn_rel...)
  linux_chromium_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_rel/bu...)

[ccameron, 2014-05-12 20:11:36]

The CQ bit was checked by ccameron@chromium.org

[commit-bot: I haz the power, 2014-05-12 20:12:58]

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

[ccameron, 2014-05-12 21:07:03]

The CQ bit was unchecked by ccameron@chromium.org

[ccameron, 2014-05-12 22:11:58]

The CQ bit was checked by ccameron@chromium.org

[commit-bot: I haz the power, 2014-05-12 22:13:02]

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

[commit-bot: I haz the power, 2014-05-13 01:00:38]

Change committed as 269946