Start of hardware overlay support in CC with Ubercompositor.

Start of hardware overlay support in CC with Ubercompositor.

I'm trying to introduce everything as small unit tested pieces.

This adds some machinery for checking if quads inside a render pass could
be placed into an overlay. A capability checker is added to the output
surface, so that a particular overlay configuration could be validated
against a specific display device. If an external monitor is plugged in,
its output surface may behave differently that that of the primary on
a laptop, for example.

The intention is for OverlayCandidates checker to be created as part of
BrowserCompositorOutputSurface where the actual hardware knowledge can
be delegated to the Ozone platform and the HW specific bits can live there,
leaving CC and content platform agnostic.

BUG=

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

[alexst (slow to review), 2014-03-12 15:05:40]

Please take a look at the first of n patched in CC overlay work.

I am making baby step here and trying to break it up into small pieces.

The rough end to end prototype is here for a a better idead of the bigger
picture. https://codereview.chromium.org/132543002/#ps40002

[piman, 2014-03-14 03:42:33]

+danakj in cc so that more people can get familiar with this new code and
concepts.

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_candidates.h
File cc/output/overlay_candidates.h (right):

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_candidates...
cc/output/overlay_candidates.h:43: unsigned resource_id;
Will we need things like blending mode or something? I suppose that can come in
time as we expand support?

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_candidates...
cc/output/overlay_candidates.h:56: virtual void
CheckOverlaySupport(OverlaySurfaceCandidateList* surfaces);
pure virtual?

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_candidates...
File cc/output/overlay_candidates_unittest.cc (right):

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_candidates...
cc/output/overlay_candidates_unittest.cc:24: static const gfx::PointF
uv_bottom_right(1.0f, 1.0f);
nit: naming kOverlayRect, etc.
Also, you don't need static since you're in an anonymous namespace.

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_candidates...
cc/output/overlay_candidates_unittest.cc:60: }
note: you can use gpu::Mailbox::Generate() now. It's all client side, and with
no side effect.

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_candidates...
cc/output/overlay_candidates_unittest.cc:65: EXPECT_EQ(nullptr,
output_surface.overlay_candidates());
nit: we don't (yet) allow nullptr because we still have non-c++11 compilers.

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_candidates...
cc/output/overlay_candidates_unittest.cc:68: EXPECT_NE(nullptr,
output_surface.overlay_candidates());
nit: nullptr

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_candidates...
cc/output/overlay_candidates_unittest.cc:71: TEST(OverlayCandidatesTest,
ResourceTest) {
This is really an OverlayRenderer test

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_candidates...
cc/output/overlay_candidates_unittest.cc:145: EXPECT_EQ(expected_pass_count,
pass_list.size());
nit: ASSERT_EQ since you will dereference the elements

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_renderer.cc
File cc/output/overlay_renderer.cc (right):

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_renderer.c...
cc/output/overlay_renderer.cc:25: ResourceProvider* resource_provider_;
nit: DISALLOW_COPY_AND_ASSIGN

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_renderer.c...
cc/output/overlay_renderer.cc:33: bool
SingleOverlayOnTop::Attempt(RenderPassList* render_passes_in_draw_order) {
I think it would be nice to expose this so that we can test it directly.

The OverlayCandidatesTest may not scale as we add more strategies.

Also, I think it would be useful to test negative cases, e.g. the trivial ones
(>1 render pass) but also cases that would fail below.

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_renderer.c...
cc/output/overlay_renderer.cc:50: return false;
You're only setting candidate_quad right before you break. I don't think this
condition can ever be true.

Did you intending for this to catch cases where there's any quad after the
candidate (to avoid any potential intersection)?


If you don't want to allow any quad in front of the candidate (very reasonable
for the simplest strategy) it seems like you could do away with the loop, by
only checking the front-most quad, and promote it iff it satisfies the
conditions.
It would also allow more cases (e.g. if the first and last quad are promotable
textures, current code would fail, whereas we could promote the frontmost one)

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_renderer.c...
cc/output/overlay_renderer.cc:79:
quad.quadTransform().TransformRect(&float_rect);
This really computes the bounding box of the transformed rect. I don't think
it's the right thing to do in the general case... don't we want to extract an
"OverlayTransform" out of the transform first (if appropriate, otherwise fail),
and pass that to candidate?

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_renderer.c...
cc/output/overlay_renderer.cc:94: quad_list.take((candidate_quad + 1).base());
I think it would be clearer if candidate_quad was a simple QuadList::iterator,
and the reverse_iterator->iterator conversion happened when we assign
candidate_quad.

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_renderer.c...
cc/output/overlay_renderer.cc:96:
overlay_pass->quad_list.push_back(overlay_quad.PassAs<DrawQuad>());
nit: just Pass() ?

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_renderer.c...
cc/output/overlay_renderer.cc:98: overlay_pass.PassAs<RenderPass>());
nit: just Pass()?

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_renderer.c...
cc/output/overlay_renderer.cc:118: for (size_t i = 0; i < strategies_.size();
i++) {
nit: use iterators and win on the bounds checks.

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_renderer.h
File cc/output/overlay_renderer.h (right):

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_renderer.h...
cc/output/overlay_renderer.h:17: class CC_EXPORT OverlayRenderer {
Naming nit: OverlayRenderer sounds like it derives from cc::Renderer, i.e. be an
alternative for GLRenderer or something. Any alternative you could think of?

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_renderer.h...
cc/output/overlay_renderer.h:22: virtual bool Attempt(RenderPassList*
render_passes_in_draw_order) = 0;
Could you document a bit the contract? It sounds like it returns true if it
promoted at least one (or all?) overlay, and iff it returns true it would have
mutated the RenderPassList?

https://codereview.chromium.org/197223003/diff/1/cc/quads/render_pass.h
File cc/quads/render_pass.h (right):

https://codereview.chromium.org/197223003/diff/1/cc/quads/render_pass.h#newco...
cc/quads/render_pass.h:118: // inside it is presented as is.
nit: this would be a great comment to have on the enum rather than here.

https://codereview.chromium.org/197223003/diff/1/cc/quads/render_pass.h#newco...
cc/quads/render_pass.h:119: HwOverlayState overlay_state;
Generally, adding a field here requires it to be added to
ParamTraits<cc::RenderPass> in cc_messages.cc (and also to corresponding tests).

That said, in this case I'm not sure we'd ever want to IPC the value of this
field. If not indeed, we should simply add a DCHECK in
ParamTraits<cc::RenderPass>::Write that it's the default value.

https://codereview.chromium.org/197223003/diff/1/cc/quads/render_pass_unittes...
File cc/quads/render_pass_unittest.cc (right):

https://codereview.chromium.org/197223003/diff/1/cc/quads/render_pass_unittes...
cc/quads/render_pass_unittest.cc:25: // Copy() tests.
ahem

https://codereview.chromium.org/197223003/diff/1/cc/resources/resource_provid...
File cc/resources/resource_provider.h (right):

https://codereview.chromium.org/197223003/diff/1/cc/resources/resource_provid...
cc/resources/resource_provider.h:442: bool has_native_buffer_backing;
nit: Similar to comment in TextureMailbox, this may be a bit confusing (what's a
native buffer backing really?). We could do allow_overlay here too.

https://codereview.chromium.org/197223003/diff/1/cc/resources/texture_mailbox.h
File cc/resources/texture_mailbox.h (right):

https://codereview.chromium.org/197223003/diff/1/cc/resources/texture_mailbox...
cc/resources/texture_mailbox.h:43: bool hw_backed() const { return hw_backed_; }
nit: hw_backed is misleading. Regular textures are hardware-backed :)
How about allow_overlays or something like that?

[enne (OOO), 2014-03-14 18:13:41]

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_candidates.h
File cc/output/overlay_candidates.h (right):

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_candidates...
cc/output/overlay_candidates.h:19: class CC_EXPORT OverlayCandidates {
bikeshed: If it answers questions, maybe this is an OverlayCandidateGenerator?
OverlayCandidateValidator? It seems more like a "verb" class than a "noun"
class.

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_candidates...
cc/output/overlay_candidates.h:30: struct OverlaySurfaceCandidate {
Move this out to a separate file, to narrow visibility? Some class will deal
with OverlayCandidate but not with OverlayCandidates it seems.

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_candidates...
cc/output/overlay_candidates.h:40: // Crop within the buffer to be placed inside
|display_rect|.
Can you say that this is in uv space and not in pixel space? Or maybe even call
it uv_rect?

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_candidates...
cc/output/overlay_candidates.h:55: // to be tranditionally composited.
typo

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_candidates...
File cc/output/overlay_candidates_unittest.cc (right):

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_candidates...
cc/output/overlay_candidates_unittest.cc:28: class SingleOverlayCandidate :
public OverlayCandidates {
This naming is a bit awkward.  Singular "FooOverlayCandidate" derives from
plural "OverlayCandidates".

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_renderer.cc
File cc/output/overlay_renderer.cc (right):

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_renderer.c...
cc/output/overlay_renderer.cc:86:
capability_checker_->CheckOverlaySupport(&candidates);
I'm sure there's a wrinkle I'm not seeing, but why can't this Check function
just return true if it can handle the entire list? Is this so that you could
hand it multiple candidates and maybe it could choose to handle some of them?

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_renderer.h
File cc/output/overlay_renderer.h (right):

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_renderer.h...
cc/output/overlay_renderer.h:17: class CC_EXPORT OverlayRenderer {
On 2014/03/14 03:42:34, piman wrote:
> Naming nit: OverlayRenderer sounds like it derives from cc::Renderer, i.e. be
an
> alternative for GLRenderer or something. Any alternative you could think of?

OverlayProcessor? OverlayPassProcessor?

https://codereview.chromium.org/197223003/diff/1/cc/quads/render_pass.h
File cc/quads/render_pass.h (right):

https://codereview.chromium.org/197223003/diff/1/cc/quads/render_pass.h#newco...
cc/quads/render_pass.h:65: enum HwOverlayState { NO_OVERLAY, RENDER_AND_OVERLAY,
SIMPLE_OVERLAY, };
bikeshed: maybe just OverlayState? Are there other kinds of overlays?

[alexst (slow to review), 2014-03-14 19:54:21]

Preparing new patch, thank you for the comments, enne, piman.

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_candidates.h
File cc/output/overlay_candidates.h (right):

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_candidates...
cc/output/overlay_candidates.h:19: class CC_EXPORT OverlayCandidates {
On 2014/03/14 18:13:41, enne wrote:
> bikeshed: If it answers questions, maybe this is an OverlayCandidateGenerator?
> OverlayCandidateValidator? It seems more like a "verb" class than a "noun"
> class.

This name is a result of bikeshedding elsewhere. :) But I'm not attached to it
and will play by CC rules here. OverlayCandidateValidator sounds good to me.

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_candidates...
cc/output/overlay_candidates.h:43: unsigned resource_id;
On 2014/03/14 03:42:34, piman wrote:
> Will we need things like blending mode or something? I suppose that can come
in
> time as we expand support?

Yeah, I was going for a minimal subset and omitted a few other things too. I'll
add other fields once more stuff is in place.

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_candidates...
cc/output/overlay_candidates.h:55: // to be tranditionally composited.
On 2014/03/14 18:13:41, enne wrote:
> typo

Done.

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_candidates...
cc/output/overlay_candidates.h:56: virtual void
CheckOverlaySupport(OverlaySurfaceCandidateList* surfaces);
On 2014/03/14 03:42:34, piman wrote:
> pure virtual?

Done.

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_candidates...
File cc/output/overlay_candidates_unittest.cc (right):

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_candidates...
cc/output/overlay_candidates_unittest.cc:24: static const gfx::PointF
uv_bottom_right(1.0f, 1.0f);
On 2014/03/14 03:42:34, piman wrote:
> nit: naming kOverlayRect, etc.
> Also, you don't need static since you're in an anonymous namespace.

Done.

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_candidates...
cc/output/overlay_candidates_unittest.cc:60: }
On 2014/03/14 03:42:34, piman wrote:
> note: you can use gpu::Mailbox::Generate() now. It's all client side, and with
> no side effect.

Done.

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_candidates...
cc/output/overlay_candidates_unittest.cc:65: EXPECT_EQ(nullptr,
output_surface.overlay_candidates());
On 2014/03/14 03:42:34, piman wrote:
> nit: we don't (yet) allow nullptr because we still have non-c++11 compilers.

Done.

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_candidates...
cc/output/overlay_candidates_unittest.cc:68: EXPECT_NE(nullptr,
output_surface.overlay_candidates());
On 2014/03/14 03:42:34, piman wrote:
> nit: nullptr

Done.

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_candidates...
cc/output/overlay_candidates_unittest.cc:145: EXPECT_EQ(expected_pass_count,
pass_list.size());
On 2014/03/14 03:42:34, piman wrote:
> nit: ASSERT_EQ since you will dereference the elements

Done.

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_renderer.cc
File cc/output/overlay_renderer.cc (right):

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_renderer.c...
cc/output/overlay_renderer.cc:25: ResourceProvider* resource_provider_;
On 2014/03/14 03:42:34, piman wrote:
> nit: DISALLOW_COPY_AND_ASSIGN

Done.

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_renderer.c...
cc/output/overlay_renderer.cc:33: bool
SingleOverlayOnTop::Attempt(RenderPassList* render_passes_in_draw_order) {
On 2014/03/14 03:42:34, piman wrote:
> I think it would be nice to expose this so that we can test it directly.
> 
> The OverlayCandidatesTest may not scale as we add more strategies.
> 
> Also, I think it would be useful to test negative cases, e.g. the trivial ones
> (>1 render pass) but also cases that would fail below.

I was planning to do it as we added more strategies, but might as well rip it
out into a separate file now and rig the class that uses it to be more testable.

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_renderer.c...
cc/output/overlay_renderer.cc:50: return false;
On 2014/03/14 03:42:34, piman wrote:
> You're only setting candidate_quad right before you break. I don't think this
> condition can ever be true.
> 
> Did you intending for this to catch cases where there's any quad after the
> candidate (to avoid any potential intersection)?
> 
> 
> If you don't want to allow any quad in front of the candidate (very reasonable
> for the simplest strategy) it seems like you could do away with the loop, by
> only checking the front-most quad, and promote it iff it satisfies the
> conditions.
> It would also allow more cases (e.g. if the first and last quad are promotable
> textures, current code would fail, whereas we could promote the frontmost one)

You are right, I was simplifying old test code for this and it need not be as
wordy.

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_renderer.c...
cc/output/overlay_renderer.cc:79:
quad.quadTransform().TransformRect(&float_rect);
On 2014/03/14 03:42:34, piman wrote:
> This really computes the bounding box of the transformed rect. I don't think
> it's the right thing to do in the general case... don't we want to extract an
> "OverlayTransform" out of the transform first (if appropriate, otherwise
fail),
> and pass that to candidate?

This meant to have a check for identity or translation and fail otherwise. I
want to write the quadTransform -> overlayTransform carefully and separately.

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_renderer.c...
cc/output/overlay_renderer.cc:86:
capability_checker_->CheckOverlaySupport(&candidates);
On 2014/03/14 18:13:41, enne wrote:
> I'm sure there's a wrinkle I'm not seeing, but why can't this Check function
> just return true if it can handle the entire list? Is this so that you could
> hand it multiple candidates and maybe it could choose to handle some of them?

Exactly right. Maybe HW can't handle 4 things, but it can handle 3 if we
manually collapsed the bottom 2 layers. The checker can signal that.

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_renderer.h
File cc/output/overlay_renderer.h (right):

https://codereview.chromium.org/197223003/diff/1/cc/output/overlay_renderer.h...
cc/output/overlay_renderer.h:17: class CC_EXPORT OverlayRenderer {
On 2014/03/14 18:13:41, enne wrote:
> On 2014/03/14 03:42:34, piman wrote:
> > Naming nit: OverlayRenderer sounds like it derives from cc::Renderer, i.e.
be
> an
> > alternative for GLRenderer or something. Any alternative you could think of?
> 
> OverlayProcessor? OverlayPassProcessor?

Maybe OverlayStrategyProcessor?

https://codereview.chromium.org/197223003/diff/1/cc/quads/render_pass.h
File cc/quads/render_pass.h (right):

https://codereview.chromium.org/197223003/diff/1/cc/quads/render_pass.h#newco...
cc/quads/render_pass.h:119: HwOverlayState overlay_state;
On 2014/03/14 03:42:34, piman wrote:
> Generally, adding a field here requires it to be added to
> ParamTraits<cc::RenderPass> in cc_messages.cc (and also to corresponding
tests).
> 
> That said, in this case I'm not sure we'd ever want to IPC the value of this
> field. If not indeed, we should simply add a DCHECK in
> ParamTraits<cc::RenderPass>::Write that it's the default value.

Yes, this should only exist in one process. I added a DCHECK, thank you for
noting that.

https://codereview.chromium.org/197223003/diff/1/cc/quads/render_pass_unittes...
File cc/quads/render_pass_unittest.cc (right):

https://codereview.chromium.org/197223003/diff/1/cc/quads/render_pass_unittes...
cc/quads/render_pass_unittest.cc:25: // Copy() tests.
On 2014/03/14 03:42:34, piman wrote:
> ahem

Right! :)

https://codereview.chromium.org/197223003/diff/1/cc/resources/texture_mailbox.h
File cc/resources/texture_mailbox.h (right):

https://codereview.chromium.org/197223003/diff/1/cc/resources/texture_mailbox...
cc/resources/texture_mailbox.h:43: bool hw_backed() const { return hw_backed_; }
On 2014/03/14 03:42:34, piman wrote:
> nit: hw_backed is misleading. Regular textures are hardware-backed :)
> How about allow_overlays or something like that?

I went back and forth on the name and abbreviated my original one, 
backed_by_a_buffer_hardware_overlays_or_fast_2d_blitters_can_scan_from_directly_.
:) 

Let's go with allow_overlays, though the word overlay is a bit overused and
technically the hardware can decide to task a fast blitter or some such instead,
hence the generic name. But I suppose "overlay" is used in other places so this
will be consistent.

[alexst (slow to review), 2014-03-18 14:16:43]

PTAL

[enne (OOO), 2014-03-18 17:35:13]

lgtm % piman

https://codereview.chromium.org/197223003/diff/30001/cc/output/overlay_candid...
File cc/output/overlay_candidate.cc (right):

https://codereview.chromium.org/197223003/diff/30001/cc/output/overlay_candid...
cc/output/overlay_candidate.cc:12: uv_rect(0, 0, 1, 1),
nit: Chrome style says float literals should be 0.f, 0.f, 1.f, 1.f

https://codereview.chromium.org/197223003/diff/30001/cc/output/overlay_proces...
File cc/output/overlay_processor.h (right):

https://codereview.chromium.org/197223003/diff/30001/cc/output/overlay_proces...
cc/output/overlay_processor.h:31: OverlayProcessor(OutputSurface* surface,
ResourceProvider* resource_provider);
nit: order the ctor before the dtor

https://codereview.chromium.org/197223003/diff/30001/cc/output/overlay_strate...
File cc/output/overlay_strategy_single_on_top.cc (right):

https://codereview.chromium.org/197223003/diff/30001/cc/output/overlay_strate...
cc/output/overlay_strategy_single_on_top.cc:73: return true;
Should this return false if the texture quad wasn't put in an overlay?

[piman, 2014-03-18 23:46:07]

Couple of things left, mostly being conservative about rejects, and nits.

https://codereview.chromium.org/197223003/diff/50001/cc/output/overlay_strate...
File cc/output/overlay_strategy_single_on_top.cc (right):

https://codereview.chromium.org/197223003/diff/50001/cc/output/overlay_strate...
cc/output/overlay_strategy_single_on_top.cc:24: if
(render_passes_in_draw_order->size() != 1 || !capability_checker_)
nit: actually, do we even care about the render pass size? If we have multiple
passes, as long as we're only looking at the root pass, as long as we decided
that the texture quad for consideration isn't overlapped by anything (since it's
last), it doesn't matter if this "anything" comes from a pass or not... When we
have multiple pass, the way other passes come into play is by having references
to them from RenderPassDrawQuads in the root pass. I think we'd still be correct
if we remove the size != 1 check, and more general.

https://codereview.chromium.org/197223003/diff/50001/cc/output/overlay_strate...
cc/output/overlay_strategy_single_on_top.cc:49: const TextureDrawQuad& quad =
*TextureDrawQuad::MaterialCast(candidate_quad);
nit: we could do this only once above, before we grab the resource id.
Also, we should do all the rejecting early, before we allocate memory (by
pushing back into candidates).

https://codereview.chromium.org/197223003/diff/50001/cc/output/overlay_strate...
cc/output/overlay_strategy_single_on_top.cc:50: if
(!quad.quadTransform().IsIdentityOrTranslation())
Should we also reject if quad.shared_quad_state->opacity != 1? Also, I think
blend_mode != kSrcOver_Mode and probably something with quad.needs_blending,
vertex_opacity, background_color... flipped? premultiplied_alpha?

We should be conservative first, and then add support as we can.

[alexst (slow to review), 2014-03-19 16:17:26]

Addressed comments, more conservative protection added, plus more tests to
verify it all.

PTAL

[piman, 2014-03-19 16:34:39]

lgtm

[alexst (slow to review), 2014-03-19 16:49:48]

The CQ bit was checked by alexst@chromium.org

[commit-bot: I haz the power, 2014-03-19 16:50:50]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/alexst@chromium.org/197223003/80001

[commit-bot: I haz the power, 2014-03-19 16:54:20]

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

[commit-bot: I haz the power, 2014-03-19 16:54:21]

Try jobs failed on following builders:
  tryserver.chromium on linux_chromium_clang_dbg

[alexst (slow to review), 2014-03-19 17:02:18]

The CQ bit was checked by alexst@chromium.org

[commit-bot: I haz the power, 2014-03-19 17:03:39]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/alexst@chromium.org/197223003/80001

[commit-bot: I haz the power, 2014-03-19 17:09:59]

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

[commit-bot: I haz the power, 2014-03-19 17:10:00]

Try jobs failed on following builders:
  tryserver.chromium on linux_chromium_clang_dbg

[alexst (slow to review), 2014-03-19 17:40:03]

The CQ bit was checked by alexst@chromium.org

[commit-bot: I haz the power, 2014-03-19 17:40:58]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/alexst@chromium.org/197223003/100001

[commit-bot: I haz the power, 2014-03-19 18:00:21]

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

[commit-bot: I haz the power, 2014-03-19 18:00:22]

Try jobs failed on following builders:
  tryserver.chromium on linux_chromium_clang_dbg

[alexst (slow to review), 2014-03-19 21:38:14]

The CQ bit was checked by alexst@chromium.org

[commit-bot: I haz the power, 2014-03-19 21:38:48]

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

[commit-bot: I haz the power, 2014-03-19 22:06:48]

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

[commit-bot: I haz the power, 2014-03-19 22:06:49]

Try jobs failed on following builders:
  tryserver.chromium on win_chromium_compile_dbg

[alexst (slow to review), 2014-03-19 23:22:15]

The CQ bit was checked by alexst@chromium.org

[commit-bot: I haz the power, 2014-03-19 23:23:25]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/alexst@chromium.org/197223003/160001

[commit-bot: I haz the power, 2014-03-20 05:56:42]

Change committed as 258209