Blend TextureLayer background-color at draw time.

Blend TextureLayer background-color at draw time.

This enables the following optimization:

1. The compositor will be able to disable GL blending
if the background-color is opaque.

2. For elements that paint directly to a texture layer,
i.e. accelerated canvas, video, etc., there is no need to
allocate an additional layer just to paint the background.

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

[piman, 2013-07-02 01:26:30]

A few drive-by's
Also, I think you need to support this in software_renderer too.

https://codereview.chromium.org/18432002/diff/1/cc/output/shader.cc
File cc/output/shader.cc (right):

https://codereview.chromium.org/18432002/diff/1/cc/output/shader.cc#newcode712
cc/output/shader.cc:712: texColor += background_color * (1.0 - texColor.a);
drive-by: so, this extra cost is done on every pixel, for every TextureLayer,
even those that don't specify the background color to blend, or are opaque...

Can you instead keep the existing shaders for the common case (background is
transparent or quad is opaque), so that we don't have to pay this cost for, e.g.
Pepper, renderers in Aura, scrollbars, video, ...?

Also, I believe we draw quads with alpha != 0 with blending turned off (with the
intent to discard alpha). They will render differently with this.

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

https://codereview.chromium.org/18432002/diff/1/cc/quads/texture_draw_quad.h#...
cc/quads/texture_draw_quad.h:48: SkColor background_color;
Note: you will need to update cc_messages.h to handle this field (you should get
an error in content/common/cc_messages_unittest.cc when building
content_unittests)

[enne (OOO), 2013-07-02 01:27:21]

Can you add pixel tests for this change?

https://codereview.chromium.org/18432002/diff/1/cc/output/gl_renderer.cc
File cc/output/gl_renderer.cc (right):

https://codereview.chromium.org/18432002/diff/1/cc/output/gl_renderer.cc#newc...
cc/output/gl_renderer.cc:1790: draw_cache_.background_color_data.push_back(
I don't think the draw cache should support per-quad background color.  The
texture cache feature is primarily for the nine patch layer on Android.  I think
you could get away with just a single uniform, and if the background color
changes, then just flush the cache.

https://codereview.chromium.org/18432002/diff/1/cc/output/shader.cc
File cc/output/shader.cc (right):

https://codereview.chromium.org/18432002/diff/1/cc/output/shader.cc#newcode713
cc/output/shader.cc:713: gl_FragColor = texColor * v_alpha;
How does v_alpha interact with texColor.a? If the background color is supposed
to be a layer beneath the canvas, aren't these lines out of order?

[alokp, 2013-07-02 22:03:54]

piman: I will be happy to support software-renderer. Is there a command-line
flag to enable it?

enne: I will add the pixel test once we think the patch is good enough to
commit.

https://codereview.chromium.org/18432002/diff/1/cc/output/gl_renderer.cc
File cc/output/gl_renderer.cc (right):

https://codereview.chromium.org/18432002/diff/1/cc/output/gl_renderer.cc#newc...
cc/output/gl_renderer.cc:1790: draw_cache_.background_color_data.push_back(
On 2013/07/02 01:27:22, enne wrote:
> I don't think the draw cache should support per-quad background color.  The
> texture cache feature is primarily for the nine patch layer on Android.  I
think
> you could get away with just a single uniform, and if the background color
> changes, then just flush the cache.

Done.

https://codereview.chromium.org/18432002/diff/1/cc/output/shader.cc
File cc/output/shader.cc (right):

https://codereview.chromium.org/18432002/diff/1/cc/output/shader.cc#newcode712
cc/output/shader.cc:712: texColor += background_color * (1.0 - texColor.a);
On 2013/07/02 01:26:30, piman wrote:
> drive-by: so, this extra cost is done on every pixel, for every TextureLayer,
> even those that don't specify the background color to blend, or are opaque...
> 
> Can you instead keep the existing shaders for the common case (background is
> transparent or quad is opaque), so that we don't have to pay this cost for,
e.g.
> Pepper, renderers in Aura, scrollbars, video, ...?

I was hoping to not have to keep the existing shaders. The number of shaders we
have to maintain explodes with number of options. If we have to keep the
existing shaders, the number of shaders for texture layers will be 8:
texture precision - medium, high
premultiplied - yes, no
background color - yes, no

Do you think performance penalty would be too severe to warrant this complexity?

> Also, I believe we draw quads with alpha != 0 with blending turned off (with
the
> intent to discard alpha). They will render differently with this.

I do not understand how it will render differently if background-color is (0, 0,
0, 0). Can you elaborate?

https://codereview.chromium.org/18432002/diff/1/cc/output/shader.cc#newcode713
cc/output/shader.cc:713: gl_FragColor = texColor * v_alpha;
On 2013/07/02 01:27:22, enne wrote:
> How does v_alpha interact with texColor.a? If the background color is supposed
> to be a layer beneath the canvas, aren't these lines out of order?

This order is correct for this specific use case. In case of canvas elements,
the texture layer is first drawn on top of the background layer, with global
opacity applied to the combined texture (render-surface).

But yes, it is confusing. May be the term background-color is not appropriate
here?

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

https://codereview.chromium.org/18432002/diff/1/cc/quads/texture_draw_quad.h#...
cc/quads/texture_draw_quad.h:48: SkColor background_color;
On 2013/07/02 01:26:30, piman wrote:
> Note: you will need to update cc_messages.h to handle this field (you should
get
> an error in content/common/cc_messages_unittest.cc when building
> content_unittests)

Done. Thanks for pointing it out.

[piman, 2013-07-02 22:27:53]

On Tue, Jul 2, 2013 at 3:03 PM, <alokp@chromium.org> wrote:

> piman: I will be happy to support software-renderer. Is there a
> command-line
> flag to enable it?
>
> enne: I will add the pixel test once we think the patch is good enough to
> commit.
>
>
>
> https://codereview.chromium.**org/18432002/diff/1/cc/output/**
>
gl_renderer.cc<https://codereview.chromium.org/18432002/diff/1/cc/output/gl_renderer.cc>
> File cc/output/gl_renderer.cc (right):
>
> https://codereview.chromium.**org/18432002/diff/1/cc/output/**
>
gl_renderer.cc#newcode1790<https://codereview.chromium.org/18432002/diff/1/cc/output/gl_renderer.cc#newcode1790>
> cc/output/gl_renderer.cc:1790:
> draw_cache_.background_color_**data.push_back(
> On 2013/07/02 01:27:22, enne wrote:
>
>> I don't think the draw cache should support per-quad background color.
>>
>  The
>
>> texture cache feature is primarily for the nine patch layer on
>>
> Android.  I think
>
>> you could get away with just a single uniform, and if the background
>>
> color
>
>> changes, then just flush the cache.
>>
>
> Done.
>
>
>
https://codereview.chromium.**org/18432002/diff/1/cc/output/**shader.cc<https...
> File cc/output/shader.cc (right):
>
> https://codereview.chromium.**org/18432002/diff/1/cc/output/**
>
shader.cc#newcode712<https://codereview.chromium.org/18432002/diff/1/cc/output/shader.cc#newcode712>
> cc/output/shader.cc:712: texColor += background_color * (1.0 -
> texColor.a);
> On 2013/07/02 01:26:30, piman wrote:
>
>> drive-by: so, this extra cost is done on every pixel, for every
>>
> TextureLayer,
>
>> even those that don't specify the background color to blend, or are
>>
> opaque...
>
>  Can you instead keep the existing shaders for the common case
>>
> (background is
>
>> transparent or quad is opaque), so that we don't have to pay this cost
>>
> for, e.g.
>
>> Pepper, renderers in Aura, scrollbars, video, ...?
>>
>
> I was hoping to not have to keep the existing shaders. The number of
> shaders we have to maintain explodes with number of options. If we have
> to keep the existing shaders, the number of shaders for texture layers
> will be 8:
> texture precision - medium, high
> premultiplied - yes, no
> background color - yes, no
>
> Do you think performance penalty would be too severe to warrant this
> complexity?


We're talking about our inner-most loop, it runs on several million pixels
every frame. I don't think it's ok to make it slower.
I'd rather support a way to make the complexity manageable, e.g. by having
a shader generator.


>
>
>  Also, I believe we draw quads with alpha != 0 with blending turned off
>>
> (with the
>
>> intent to discard alpha). They will render differently with this.
>>
>
> I do not understand how it will render differently if background-color
> is (0, 0, 0, 0). Can you elaborate?


But if background-color is not 0, then it will be different, won't it?


>
>
> https://codereview.chromium.**org/18432002/diff/1/cc/output/**
>
shader.cc#newcode713<https://codereview.chromium.org/18432002/diff/1/cc/output/shader.cc#newcode713>
> cc/output/shader.cc:713: gl_FragColor = texColor * v_alpha;
> On 2013/07/02 01:27:22, enne wrote:
>
>> How does v_alpha interact with texColor.a? If the background color is
>>
> supposed
>
>> to be a layer beneath the canvas, aren't these lines out of order?
>>
>
> This order is correct for this specific use case. In case of canvas
> elements, the texture layer is first drawn on top of the background
> layer, with global opacity applied to the combined texture
> (render-surface).
>
> But yes, it is confusing. May be the term background-color is not
> appropriate here?


>
> https://codereview.chromium.**org/18432002/diff/1/cc/quads/**
>
texture_draw_quad.h<https://codereview.chromium.org/18432002/diff/1/cc/quads/texture_draw_quad.h>
> File cc/quads/texture_draw_quad.h (right):
>
> https://codereview.chromium.**org/18432002/diff/1/cc/quads/**
>
texture_draw_quad.h#newcode48<https://codereview.chromium.org/18432002/diff/1/cc/quads/texture_draw_quad.h#newcode48>
> cc/quads/texture_draw_quad.h:**48: SkColor background_color;
> On 2013/07/02 01:26:30, piman wrote:
>
>> Note: you will need to update cc_messages.h to handle this field (you
>>
> should get
>
>> an error in content/common/cc_messages_**unittest.cc when building
>> content_unittests)
>>
>
> Done. Thanks for pointing it out.
>
>
https://codereview.chromium.**org/18432002/<https://codereview.chromium.org/1...
>

[alokp, 2013-07-02 22:35:53]

> 
> We're talking about our inner-most loop, it runs on several million pixels
> every frame. I don't think it's ok to make it slower.
> I'd rather support a way to make the complexity manageable, e.g. by having
> a shader generator.
> 

OK. I will see if I can manage the complexity without having to write a shader
generator.

> 
> But if background-color is not 0, then it will be different, won't it?
> 

TextureDrawQuad::background_color is always 0 unless
TextureLayer::blend_background_color is set.

[alokp, 2013-07-02 22:36:05]

https://codereview.chromium.org/18432002/diff/11001/cc/layers/texture_layer_i...
File cc/layers/texture_layer_impl.cc (right):

https://codereview.chromium.org/18432002/diff/11001/cc/layers/texture_layer_i...
cc/layers/texture_layer_impl.cc:91: background_color() : SK_ColorTRANSPARENT;
> But if background-color is not 0, then it will be different, won't it?
> 

TextureDrawQuad::background_color is always 0 unless
TextureLayer::blend_background_color is set.

[enne (OOO), 2013-07-02 23:08:29]

https://codereview.chromium.org/18432002/diff/1/cc/output/shader.cc
File cc/output/shader.cc (right):

https://codereview.chromium.org/18432002/diff/1/cc/output/shader.cc#newcode713
cc/output/shader.cc:713: gl_FragColor = texColor * v_alpha;
On 2013/07/02 22:03:54, Alok Priyadarshi wrote:

> But yes, it is confusing. May be the term background-color is not appropriate
> here?

I think it's still correct.  I guess if I think about a content layer that has a
background color and an opacity, I would expect that the background color would
be blended with the rest of the content before having the opacity applied.

[alokp, 2013-07-03 18:09:11]

It is a bit ugly but I have restored the original shaders for textures without
background. Other than adding pixel tests and implementing it in software
renderer, are there any any other comments?

piman: Is there a flag to enable the software renderer?

[piman, 2013-07-03 19:54:54]

On 2013/07/03 18:09:11, Alok Priyadarshi wrote:
> It is a bit ugly but I have restored the original shaders for textures without
> background. Other than adding pixel tests and implementing it in software
> renderer, are there any any other comments?
> 
> piman: Is there a flag to enable the software renderer?

+jbauman who probably knows the current incantation.

Ideally, this could be verified with pixel tests though.

[piman, 2013-07-03 20:11:12]

https://codereview.chromium.org/18432002/diff/16001/cc/output/gl_renderer.cc
File cc/output/gl_renderer.cc (right):

https://codereview.chromium.org/18432002/diff/16001/cc/output/gl_renderer.cc#...
cc/output/gl_renderer.cc:1821: const TextureDrawQuad* quad) {
FYI this method was removed by https://codereview.chromium.org/18582003/

https://codereview.chromium.org/18432002/diff/16001/content/common/cc_message...
File content/common/cc_messages_unittest.cc (right):

https://codereview.chromium.org/18432002/diff/16001/content/common/cc_message...
content/common/cc_messages_unittest.cc:350: arbitrary_color,
Please also add the field to Compare(const TextureDrawQuad* a, const
TextureDrawQuad* b)

https://codereview.chromium.org/18432002/diff/16001/webkit/renderer/composito...
File webkit/renderer/compositor_bindings/web_external_texture_layer_impl.h
(right):

https://codereview.chromium.org/18432002/diff/16001/webkit/renderer/composito...
webkit/renderer/compositor_bindings/web_external_texture_layer_impl.h:42: #if
WEB_EXTERNAL_TEXTURE_LAYER_HAS_BLEND_BACKGROUND_COLOR
nit: you don't need an ifdef to add the virtual method. Saves you a cleanup CL
later.

[alokp, 2013-07-09 00:08:06]

Added pixel test and implemented the blending in software renderer.

https://codereview.chromium.org/18432002/diff/16001/cc/output/gl_renderer.cc
File cc/output/gl_renderer.cc (right):

https://codereview.chromium.org/18432002/diff/16001/cc/output/gl_renderer.cc#...
cc/output/gl_renderer.cc:1821: const TextureDrawQuad* quad) {
On 2013/07/03 20:11:12, piman wrote:
> FYI this method was removed by https://codereview.chromium.org/18582003/

Thanks for the heads up.

https://codereview.chromium.org/18432002/diff/16001/content/common/cc_message...
File content/common/cc_messages_unittest.cc (right):

https://codereview.chromium.org/18432002/diff/16001/content/common/cc_message...
content/common/cc_messages_unittest.cc:350: arbitrary_color,
On 2013/07/03 20:11:12, piman wrote:
> Please also add the field to Compare(const TextureDrawQuad* a, const
> TextureDrawQuad* b)

Done.

https://codereview.chromium.org/18432002/diff/16001/webkit/renderer/composito...
File webkit/renderer/compositor_bindings/web_external_texture_layer_impl.h
(right):

https://codereview.chromium.org/18432002/diff/16001/webkit/renderer/composito...
webkit/renderer/compositor_bindings/web_external_texture_layer_impl.h:42: #if
WEB_EXTERNAL_TEXTURE_LAYER_HAS_BLEND_BACKGROUND_COLOR
On 2013/07/03 20:11:12, piman wrote:
> nit: you don't need an ifdef to add the virtual method. Saves you a cleanup CL
> later.

I know but a WK reviewer insisted I do it in multiple steps.

https://codereview.chromium.org/18432002/diff/28001/cc/output/software_render...
File cc/output/software_renderer.cc (right):

https://codereview.chromium.org/18432002/diff/28001/cc/output/software_render...
cc/output/software_renderer.cc:362: bool needs_layer = blend_background &&
(current_paint_.getAlpha() != 0xFF);
reed@: Is there a paint mode in skia that will avoid having to create this
offscreen buffer?

We need to blend a bitmap over a solid color; blend the result with a global
alpha.

[alokp, 2013-07-10 17:24:42]

reviewers: PTAL. I think this is ready for CQ.

[enne (OOO), 2013-07-10 17:52:13]

Can you also add tests for the premultiplied vs not premultiplied path?  I'd
like any shader we add to at least be minimally exercised by one pixel test.

https://codereview.chromium.org/18432002/diff/33001/cc/output/gl_renderer.cc
File cc/output/gl_renderer.cc (right):

https://codereview.chromium.org/18432002/diff/33001/cc/output/gl_renderer.cc#...
cc/output/gl_renderer.cc:2841: if (!program)
style nit: {}

https://codereview.chromium.org/18432002/diff/33001/webkit/renderer/composito...
File webkit/renderer/compositor_bindings/web_external_texture_layer_impl.h
(right):

https://codereview.chromium.org/18432002/diff/33001/webkit/renderer/composito...
webkit/renderer/compositor_bindings/web_external_texture_layer_impl.h:44: #if
WEB_EXTERNAL_TEXTURE_LAYER_HAS_BLEND_BACKGROUND_COLOR
I agree with piman's previous comment.  You don't need the #ifs here; this is a
virtual function.  It will save you a cleanup change later.

[alokp, 2013-07-10 19:06:19]

Added test for non-premultiplied path. Note that software renderer does not
support non-premultiplied alpha yet.

https://codereview.chromium.org/18432002/diff/33001/cc/output/gl_renderer.cc
File cc/output/gl_renderer.cc (right):

https://codereview.chromium.org/18432002/diff/33001/cc/output/gl_renderer.cc#...
cc/output/gl_renderer.cc:2841: if (!program)
On 2013/07/10 17:52:13, enne wrote:
> style nit: {}

Done.

https://codereview.chromium.org/18432002/diff/33001/webkit/renderer/composito...
File webkit/renderer/compositor_bindings/web_external_texture_layer_impl.h
(right):

https://codereview.chromium.org/18432002/diff/33001/webkit/renderer/composito...
webkit/renderer/compositor_bindings/web_external_texture_layer_impl.h:44: #if
WEB_EXTERNAL_TEXTURE_LAYER_HAS_BLEND_BACKGROUND_COLOR
On 2013/07/10 17:52:13, enne wrote:
> I agree with piman's previous comment.  You don't need the #ifs here; this is
a
> virtual function.  It will save you a cleanup change later.

Done.

[enne (OOO), 2013-07-10 19:56:00]

lgtm.

I assume there's going to be a Blink-side change to not create layers for this
case once this lands?

[alokp, 2013-07-10 19:58:14]

On 2013/07/10 19:56:00, enne wrote:
> lgtm.
> 
> I assume there's going to be a Blink-side change to not create layers for this
> case once this lands?

Right. Thanks enne!

piman@: Do you see any other issues?

[piman, 2013-07-10 19:58:30]

LGTM for content/

[commit-bot: I haz the power, 2013-07-10 20:03:57]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/alokp@chromium.org/18432002/34028

[commit-bot: I haz the power, 2013-07-10 20:14:28]

Retried try job too often on chromium_presubmit for step(s) presubmit
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=chromium_p...

[alokp, 2013-07-10 20:24:48]

cdn@: Could you review cc_messages.h

[alokp, 2013-07-11 16:07:12]

+palmer for IPC review.

cdn, palmer: Could any of you review cc_messages.h please?

[palmer, 2013-07-11 18:37:22]

https://codereview.chromium.org/18432002/diff/34028/cc/layers/texture_layer_i...
File cc/layers/texture_layer_impl.cc (right):

https://codereview.chromium.org/18432002/diff/34028/cc/layers/texture_layer_i...
cc/layers/texture_layer_impl.cc:111: gfx::Rect opaque_rect = contents_opaque()
|| (SkColorGetA(bg_color) == 0xFF) ?
I don't understand this. It looks like it will try to assign a boolean value to
|opaque_rect|?

[alokp, 2013-07-11 19:55:00]

https://codereview.chromium.org/18432002/diff/34028/cc/layers/texture_layer_i...
File cc/layers/texture_layer_impl.cc (right):

https://codereview.chromium.org/18432002/diff/34028/cc/layers/texture_layer_i...
cc/layers/texture_layer_impl.cc:111: gfx::Rect opaque_rect = contents_opaque()
|| (SkColorGetA(bg_color) == 0xFF) ?
On 2013/07/11 18:37:22, Chromium Palmer wrote:
> I don't understand this. It looks like it will try to assign a boolean value
to
> |opaque_rect|?

I do not think so, but would you prefer enclosing the conditional expression?

[danakj, 2013-07-11 20:34:04]

https://codereview.chromium.org/18432002/diff/34028/cc/layers/texture_layer_i...
File cc/layers/texture_layer_impl.cc (right):

https://codereview.chromium.org/18432002/diff/34028/cc/layers/texture_layer_i...
cc/layers/texture_layer_impl.cc:111: gfx::Rect opaque_rect = contents_opaque()
|| (SkColorGetA(bg_color) == 0xFF) ?
On 2013/07/11 19:55:00, Alok Priyadarshi wrote:
> On 2013/07/11 18:37:22, Chromium Palmer wrote:
> > I don't understand this. It looks like it will try to assign a boolean value
> to
> > |opaque_rect|?
> 
> I do not think so, but would you prefer enclosing the conditional expression?

How about a temp var for the boolean part

[alokp, 2013-07-11 20:42:33]

Added temp var.

https://codereview.chromium.org/18432002/diff/34028/cc/layers/texture_layer_i...
File cc/layers/texture_layer_impl.cc (right):

https://codereview.chromium.org/18432002/diff/34028/cc/layers/texture_layer_i...
cc/layers/texture_layer_impl.cc:111: gfx::Rect opaque_rect = contents_opaque()
|| (SkColorGetA(bg_color) == 0xFF) ?
On 2013/07/11 20:34:05, danakj wrote:
> On 2013/07/11 19:55:00, Alok Priyadarshi wrote:
> > On 2013/07/11 18:37:22, Chromium Palmer wrote:
> > > I don't understand this. It looks like it will try to assign a boolean
value
> > to
> > > |opaque_rect|?
> > 
> > I do not think so, but would you prefer enclosing the conditional
expression?
> 
> How about a temp var for the boolean part

Done.

[palmer, 2013-07-11 21:34:57]

IPC security LGTM

[commit-bot: I haz the power, 2013-07-11 21:42:20]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/alokp@chromium.org/18432002/5733953138...

[commit-bot: I haz the power, 2013-07-11 21:42:35]

Failed to apply patch for
webkit/renderer/compositor_bindings/web_external_texture_layer_impl.cc:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  patching file
webkit/renderer/compositor_bindings/web_external_texture_layer_impl.cc
  Hunk #1 FAILED at 73.
  1 out of 1 hunk FAILED -- saving rejects to file
webkit/renderer/compositor_bindings/web_external_texture_layer_impl.cc.rej

Patch:      
webkit/renderer/compositor_bindings/web_external_texture_layer_impl.cc
Index: webkit/renderer/compositor_bindings/web_external_texture_layer_impl.cc
diff --git
a/webkit/renderer/compositor_bindings/web_external_texture_layer_impl.cc
b/webkit/renderer/compositor_bindings/web_external_texture_layer_impl.cc
index
22da707b28cd9520c639d29d98bb0f5b53fa3b09..7ad6f380417309d9fb3ef4a09ed931bc5f96e6f3
100644
--- a/webkit/renderer/compositor_bindings/web_external_texture_layer_impl.cc
+++ b/webkit/renderer/compositor_bindings/web_external_texture_layer_impl.cc
@@ -73,6 +73,10 @@ void WebExternalTextureLayerImpl::setPremultipliedAlpha(
       premultiplied_alpha);
 }
 
+void WebExternalTextureLayerImpl::setBlendBackgroundColor(bool blend) {
+  static_cast<TextureLayer*>(layer_->layer())->SetBlendBackgroundColor(blend);
+}
+
 void WebExternalTextureLayerImpl::willModifyTexture() {
   static_cast<TextureLayer*>(layer_->layer())->WillModifyTexture();
 }

[commit-bot: I haz the power, 2013-07-11 23:40:09]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/alokp@chromium.org/18432002/69001

[commit-bot: I haz the power, 2013-07-12 00:22:54]

Sorry for I got bad news for ya.
Compile failed with a clobber build on android_clang_dbg.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_cl...
Your code is likely broken or HEAD is junk. Please ensure your
code is not broken then alert the build sheriffs.
Look at the try server FAQ for more details.

[commit-bot: I haz the power, 2013-07-12 05:06:56]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/alokp@chromium.org/18432002/69001

[commit-bot: I haz the power, 2013-07-12 05:33:52]

Change committed as 211339