Allow WebExternalTextureLayerClient to work with mailboxes.

This patch implements the necessary plumbing to allow WebExternalTextureLayerClient to be used with texture mailboxes, which allows WebGL and Canvas2D to work with ubercompositor.

CC part of this patch requests the client to prepare a mailbox instead of a texture. Compositor bindings handle interaction with Blink as well as callbacks associated with mailboxes being released.

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

[alexst (slow to review), 2013-02-28 20:06:29]

Here is the WebKit patch
https://bugs.webkit.org/show_bug.cgi?id=111097

[Ken Russell (switch to Gerrit), 2013-02-28 23:41:41]

Could you file a bug for this and describe in more detail the issues you
mention?

[piman, 2013-03-01 02:25:33]

https://codereview.chromium.org/12374028/diff/1/cc/texture_layer.h
File cc/texture_layer.h (right):

https://codereview.chromium.org/12374028/diff/1/cc/texture_layer.h#newcode29
cc/texture_layer.h:29: static scoped_refptr<TextureLayer>
create(TextureLayerClient*, bool mailbox = false);
nit: no default values (forbidden by style guide).
That should supersede createForMailbox then, right?

https://codereview.chromium.org/12374028/diff/1/webkit/compositor_bindings/we...
File webkit/compositor_bindings/web_external_texture_layer_impl.cc (right):

https://codereview.chromium.org/12374028/diff/1/webkit/compositor_bindings/we...
webkit/compositor_bindings/web_external_texture_layer_impl.cc:122:
TextureMailbox::ReleaseCallback callback =
base::Bind(&WebExternalTextureLayerImpl::mailboxReleased,
base::Unretained(this), mailbox);
I'm pretty sure Unretained is unsafe here, because the callback may outlive this
(especially with impl-side painting, ÜC etc.).
A weak pointer wouldn't be enough either because that would cause us to leak the
mailbox. We most likely need a mechanism to tell the TextureLayer to delete the
texture instead of returning it.

https://codereview.chromium.org/12374028/diff/1/webkit/compositor_bindings/we...
webkit/compositor_bindings/web_external_texture_layer_impl.cc:124:
static_cast<TextureLayer*>(layer_->layer())->setTextureMailbox(ccMailbox);
It's a bit awkward to have the pull+push mechanism here. Since the TextureLayer
knows if it's using mailboxes or not, it could call a
TextureLayerClient::prepareMailbox directly, and have that return the mailbox?

https://codereview.chromium.org/12374028/diff/1/webkit/compositor_bindings/we...
File webkit/compositor_bindings/web_external_texture_layer_impl.h (right):

https://codereview.chromium.org/12374028/diff/1/webkit/compositor_bindings/we...
webkit/compositor_bindings/web_external_texture_layer_impl.h:24: bool mailbox =
false);
nit: default value disallowed by the style guide

[alexst (slow to review), 2013-03-01 16:19:32]

On 2013/02/28 23:41:41, kbr wrote:
> Could you file a bug for this and describe in more detail the issues you
> mention?

Bug opened. It's just some implementation details like lifecycle of the callback
object, best place to copy the backbuffer and paintCompositedResultsToCanvas,
which I haven't gotten around to doing.

[alexst (slow to review), 2013-03-01 16:47:17]

Generally speaking though, does the overall approach seem reasonable to you
guys? That is, package up WebGL buffers into mailboxes; on update, recycle an
old buffer if available, create a new one otherwise.

https://codereview.chromium.org/12374028/diff/1/cc/texture_layer.h
File cc/texture_layer.h (right):

https://codereview.chromium.org/12374028/diff/1/cc/texture_layer.h#newcode29
cc/texture_layer.h:29: static scoped_refptr<TextureLayer>
create(TextureLayerClient*, bool mailbox = false);
On 2013/03/01 02:25:33, piman wrote:
> nit: no default values (forbidden by style guide).
> That should supersede createForMailbox then, right?

It's a temporary hack in the name of getting the prototype going. I'll fully
address this. Same with the weird push/pull code. Once I started poking at the
interfaces, the CL grew pretty dramatically and I wanted to keep the code churn
to a minimum for this initial review and not burden you with a bunch of
boilerplate.
I was thinking of adding a client to the createForMailbox in the final version.

https://codereview.chromium.org/12374028/diff/1/webkit/compositor_bindings/we...
File webkit/compositor_bindings/web_external_texture_layer_impl.cc (right):

https://codereview.chromium.org/12374028/diff/1/webkit/compositor_bindings/we...
webkit/compositor_bindings/web_external_texture_layer_impl.cc:122:
TextureMailbox::ReleaseCallback callback =
base::Bind(&WebExternalTextureLayerImpl::mailboxReleased,
base::Unretained(this), mailbox);

Yea, this needs work. I had a similar situation for webview and used a
scoped_refptr object with the callback to make sure there were no issues on
teardown. It's one of the things I still have to think about.

On 2013/03/01 02:25:33, piman wrote:
> I'm pretty sure Unretained is unsafe here, because the callback may outlive
this
> (especially with impl-side painting, ÜC etc.).
> A weak pointer wouldn't be enough either because that would cause us to leak
the
> mailbox. We most likely need a mechanism to tell the TextureLayer to delete
the
> texture instead of returning it.

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

On 2013/03/01 16:47:17, alexst wrote:
> Generally speaking though, does the overall approach seem reasonable to you
> guys? That is, package up WebGL buffers into mailboxes; on update, recycle an
> old buffer if available, create a new one otherwise.

Yes, at a high level there is no question this is the direction we want to go in
order to give WebGL's rendering results to the compositor. There are semantic
problems with having WebGL in the same share group as the compositor. To fix
these issues, WebGL contexts need to be in their own share group client-side.

Getting printing to work in this new scenario may be difficult. It'll be
necessary to go back to the compositor and ask it to read back the most recent
rendering results, since there is no guarantee that we will still have those
results at the WebGLRenderingContext / DrawingBuffer level.

[alexst (slow to review), 2013-03-01 22:44:13]

> Getting printing to work in this new scenario may be difficult. It'll be
> necessary to go back to the compositor and ask it to read back the most recent
> rendering results, since there is no guarantee that we will still have those
> results at the WebGLRenderingContext / DrawingBuffer level.

I was looking at this today. I think this may be the trickiest part of the whole
thing. Printing relies on the front buffer still living inside DrawingBuffer,
and like you said, with mailboxes there are no such guarantees.

[piman, 2013-03-01 23:05:15]

I think it is a similar problem to the thumbnailer / tab capture / cloud view
thing, where we want to be able to capture the data from a layer (and possibly
its subtree?), through the compositor, after we gave it ownership of the data,
and maybe we can make it happen the same way?
The main issue here though is that I think paintCompositedResultsToCanvas
expects the result synchronously whereas the other cases work asynchronously. No
matter what, getting synchronous results from the compositor's impl thread is
going to be messy.

[no sievers, 2013-03-01 23:09:21]

On 2013/03/01 23:05:15, piman wrote:
> I think it is a similar problem to the thumbnailer / tab capture / cloud view
> thing, where we want to be able to capture the data from a layer (and possibly
> its subtree?), through the compositor, after we gave it ownership of the data,
> and maybe we can make it happen the same way?
> The main issue here though is that I think paintCompositedResultsToCanvas
> expects the result synchronously whereas the other cases work asynchronously.
No
> matter what, getting synchronous results from the compositor's impl thread is
> going to be messy.

We could have an async API by having the impl thread composite to a mailbox
texture, but not sure about when you want the results in a canvas.

[jbauman, 2013-03-01 23:22:15]

On 2013/03/01 23:05:15, piman wrote:
> I think it is a similar problem to the thumbnailer / tab capture / cloud view
> thing, where we want to be able to capture the data from a layer (and possibly
> its subtree?), through the compositor, after we gave it ownership of the data,
> and maybe we can make it happen the same way?
> The main issue here though is that I think paintCompositedResultsToCanvas
> expects the result synchronously whereas the other cases work asynchronously.
No
> matter what, getting synchronous results from the compositor's impl thread is
> going to be messy.

At least for the normal threaded case you can post a task to the impl thread to
get it to hand back a copy of the texture and wait for its completion, which
isn't too bad. I'm not sure how the ubercomp case works, but hopefully it should
just be the same with added ipcs. Maybe the impl thread could hide the
async-ness from the main thread.

[piman, 2013-03-01 23:34:12]

On 2013/03/01 23:22:15, jbauman wrote:
> On 2013/03/01 23:05:15, piman wrote:
> > I think it is a similar problem to the thumbnailer / tab capture / cloud
view
> > thing, where we want to be able to capture the data from a layer (and
possibly
> > its subtree?), through the compositor, after we gave it ownership of the
data,
> > and maybe we can make it happen the same way?
> > The main issue here though is that I think paintCompositedResultsToCanvas
> > expects the result synchronously whereas the other cases work
asynchronously.
> No
> > matter what, getting synchronous results from the compositor's impl thread
is
> > going to be messy.
> 
> At least for the normal threaded case you can post a task to the impl thread
to
> get it to hand back a copy of the texture and wait for its completion, which
> isn't too bad. I'm not sure how the ubercomp case works, but hopefully it
should
> just be the same with added ipcs. Maybe the impl thread could hide the
> async-ness from the main thread.

Part of the async-ness is that we may need to wait for the commit before the
data is visible (and usable) there, so I think it goes beyond just posting a
task (i.e. more like the compositeAndReadback case). A possible out is to handle
the case on the main thread, though that certainly adds a bunch of complexity
(now we need to access a main thread context from the compositor).

[alexst (slow to review), 2013-03-14 18:24:34]

New patch, updated the webkit patch as well.

This patch assumes that mailboxes will be refcounted using client ID's.

[piman, 2013-03-14 19:54:58]

https://codereview.chromium.org/12374028/diff/16001/cc/texture_layer.cc
File cc/texture_layer.cc (right):

https://codereview.chromium.org/12374028/diff/16001/cc/texture_layer.cc#newco...
cc/texture_layer.cc:30: bool usesMailbox) {
nit: uses_mailbox

https://codereview.chromium.org/12374028/diff/16001/cc/texture_layer.cc#newco...
cc/texture_layer.cc:161: SetTextureMailbox(mailbox);
How hard would it be to change the BrowserPluginCompositingHelper to use the
TextureLayerClient::prepareTextureMailbox path, and then make SetTextureMailbox
private? It would be nice to have a single mailbox path.

As we remove the non-mailbox users, I'm sure we can shortly remove the
SetTextureId path, and possibly even the non-mailbox paths in a nearish future -
basically streamlining the code paths.

https://codereview.chromium.org/12374028/diff/16001/cc/texture_layer.h
File cc/texture_layer.h (right):

https://codereview.chromium.org/12374028/diff/16001/cc/texture_layer.h#newcode28
cc/texture_layer.h:28: bool usesMailbox);
nit: uses_mailbox, we're in chrome style now.

https://codereview.chromium.org/12374028/diff/16001/cc/texture_layer_client.h
File cc/texture_layer_client.h (right):

https://codereview.chromium.org/12374028/diff/16001/cc/texture_layer_client.h...
cc/texture_layer_client.h:26: virtual bool
prepareTextureMailbox(TextureMailbox*) = 0;
Definitely worth a comment. In particular the meaning of the return value (false
== reuse existing).

https://codereview.chromium.org/12374028/diff/16001/webkit/compositor_binding...
File webkit/compositor_bindings/web_compositor_support_impl.h (right):

https://codereview.chromium.org/12374028/diff/16001/webkit/compositor_binding...
webkit/compositor_bindings/web_compositor_support_impl.h:37: bool mailbox =
false);
nit: no default value (besides, WebCompositorSupport already has it in your
webkit patch).

https://codereview.chromium.org/12374028/diff/16001/webkit/compositor_binding...
File webkit/compositor_bindings/web_external_texture_layer_impl.cc (right):

https://codereview.chromium.org/12374028/diff/16001/webkit/compositor_binding...
webkit/compositor_bindings/web_external_texture_layer_impl.cc:127: Mailbox
availableMailbox;
nit: available_mailbox

https://codereview.chromium.org/12374028/diff/16001/webkit/compositor_binding...
File webkit/compositor_bindings/web_external_texture_layer_impl.h (right):

https://codereview.chromium.org/12374028/diff/16001/webkit/compositor_binding...
webkit/compositor_bindings/web_external_texture_layer_impl.h:47: void
mailboxReleased(const Mailbox &mailbox, unsigned syncPoint);
Does this need to be public?

https://codereview.chromium.org/12374028/diff/16001/webkit/compositor_binding...
webkit/compositor_bindings/web_external_texture_layer_impl.h:48: private:
nit: keep blank line before 'private:'
The one after isn't necessary.

[alexst (slow to review), 2013-03-14 20:37:06]

New patch.

https://codereview.chromium.org/12374028/diff/16001/cc/texture_layer.cc
File cc/texture_layer.cc (right):

https://codereview.chromium.org/12374028/diff/16001/cc/texture_layer.cc#newco...
cc/texture_layer.cc:30: bool usesMailbox) {
On 2013/03/14 19:54:58, piman wrote:
> nit: uses_mailbox

Done.

https://codereview.chromium.org/12374028/diff/16001/cc/texture_layer.cc#newco...
cc/texture_layer.cc:161: SetTextureMailbox(mailbox);
On 2013/03/14 19:54:58, piman wrote:
> How hard would it be to change the BrowserPluginCompositingHelper to use the
> TextureLayerClient::prepareTextureMailbox path, and then make
SetTextureMailbox
> private?

Shouldn't be too bad, I'll look into it.

As far as removing SetTextureId path, once the rest of the canvas code is using
mailboxes, I think browser compositor is the last user, so it should be doable.

https://codereview.chromium.org/12374028/diff/16001/cc/texture_layer.h
File cc/texture_layer.h (right):

https://codereview.chromium.org/12374028/diff/16001/cc/texture_layer.h#newcode28
cc/texture_layer.h:28: bool usesMailbox);
On 2013/03/14 19:54:58, piman wrote:
> nit: uses_mailbox, we're in chrome style now.

Done.

https://codereview.chromium.org/12374028/diff/16001/webkit/compositor_binding...
File webkit/compositor_bindings/web_compositor_support_impl.h (right):

https://codereview.chromium.org/12374028/diff/16001/webkit/compositor_binding...
webkit/compositor_bindings/web_compositor_support_impl.h:37: bool mailbox =
false);
On 2013/03/14 19:54:58, piman wrote:
> nit: no default value (besides, WebCompositorSupport already has it in your
> webkit patch).

Sigh, I thought I removed it already. Done.

https://codereview.chromium.org/12374028/diff/16001/webkit/compositor_binding...
File webkit/compositor_bindings/web_external_texture_layer_impl.cc (right):

https://codereview.chromium.org/12374028/diff/16001/webkit/compositor_binding...
webkit/compositor_bindings/web_external_texture_layer_impl.cc:127: Mailbox
availableMailbox;
On 2013/03/14 19:54:58, piman wrote:
> nit: available_mailbox

Done.

https://codereview.chromium.org/12374028/diff/16001/webkit/compositor_binding...
File webkit/compositor_bindings/web_external_texture_layer_impl.h (right):

https://codereview.chromium.org/12374028/diff/16001/webkit/compositor_binding...
webkit/compositor_bindings/web_external_texture_layer_impl.h:47: void
mailboxReleased(const Mailbox &mailbox, unsigned syncPoint);
On 2013/03/14 19:54:58, piman wrote:
> Does this need to be public?

Done.

https://codereview.chromium.org/12374028/diff/16001/webkit/compositor_binding...
webkit/compositor_bindings/web_external_texture_layer_impl.h:48: private:
On 2013/03/14 19:54:58, piman wrote:
> nit: keep blank line before 'private:'
> The one after isn't necessary.

Done.

[piman, 2013-03-14 22:17:58]

LGTM overall. Please fix the description before landing. If you want to do the
BrowserPluginCompositingHelper refactoring as a follow up, that's probably ok.

[alexst (slow to review), 2013-03-14 22:40:17]

On 2013/03/14 22:17:58, piman wrote:
> LGTM overall. Please fix the description before landing. If you want to do the
> BrowserPluginCompositingHelper refactoring as a follow up, that's probably ok.

Cool. I"ll do browser plugin separately and update the description before I land
this.

Just to make sure you saw, new WebKit patch is here
https://bugs.webkit.org/show_bug.cgi?id=111097.

There is a circular dependency, so once everyone is happy with the WebKit code,
I'll split it up to land the interfaces, land this, then land the rest of
webkit.

[commit-bot: I haz the power, 2013-04-11 17:28:33]

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

[commit-bot: I haz the power, 2013-04-11 17:28:43]

Presubmit check for 12374028-43001 failed and returned exit status 1.

INFO:root:Found 12 file(s).

Running presubmit commit checks ...
Running /b/commit-queue/workdir/chromium/PRESUBMIT.py
Running /b/commit-queue/workdir/chromium/cc/PRESUBMIT.py
Running /b/commit-queue/workdir/chromium/ui/compositor/PRESUBMIT.py

** Presubmit ERRORS **
Missing LGTM from an OWNER for these files:
    webkit/compositor_bindings/web_compositor_support_impl.h
    webkit/compositor_bindings/web_external_texture_layer_impl.cc
    webkit/compositor_bindings/web_compositor_support_impl.cc
    webkit/compositor_bindings/web_external_texture_layer_impl.h

Presubmit checks took 1.7s to calculate.

[alexst (slow to review), 2013-04-11 17:35:33]

Enne, please take a look at the compositor bindings.

[jamesr, 2013-04-11 17:36:58]

The patch description here is pretty sparse - could you add some description of
what this patch in particular does?

https://chromiumcodereview.appspot.com/12374028/diff/43001/webkit/compositor_...
File webkit/compositor_bindings/web_external_texture_layer_impl.cc (right):

https://chromiumcodereview.appspot.com/12374028/diff/43001/webkit/compositor_...
webkit/compositor_bindings/web_external_texture_layer_impl.cc:127: const
WebKit::WebExternalTextureMailbox &mailbox,
& goes with the type, not the variable name

https://chromiumcodereview.appspot.com/12374028/diff/43001/webkit/compositor_...
webkit/compositor_bindings/web_external_texture_layer_impl.cc:130: if
(lost_resource)
why is the callback invoked with lost_resource=true if we're just ignoring it in
that case? do other callers need to do something here?

https://chromiumcodereview.appspot.com/12374028/diff/43001/webkit/compositor_...
File webkit/compositor_bindings/web_external_texture_layer_impl.h (right):

https://chromiumcodereview.appspot.com/12374028/diff/43001/webkit/compositor_...
webkit/compositor_bindings/web_external_texture_layer_impl.h:49: virtual bool
PrepareTextureMailbox(cc::TextureMailbox*) OVERRIDE;
parameter needs a name

https://chromiumcodereview.appspot.com/12374028/diff/43001/webkit/compositor_...
webkit/compositor_bindings/web_external_texture_layer_impl.h:52: void
mailboxReleased(const WebKit::WebExternalTextureMailbox &mailbox,
use Chromium naming style for functions that aren't implementing WebKit API. 
This should be capitalized MailboxReleased(), although that's a bit of an
awkward name for a function.  What is this function supposed to do?  React to a
mailbox being released?

Put the & with the type name (i.e. const WK::WETM& mailbox, not const WKMETM
&callback)

https://chromiumcodereview.appspot.com/12374028/diff/43001/webkit/plugins/ppa...
File webkit/plugins/ppapi/ppapi_plugin_instance.cc (right):

https://chromiumcodereview.appspot.com/12374028/diff/43001/webkit/plugins/ppa...
webkit/plugins/ppapi/ppapi_plugin_instance.cc:2109: bool
PluginInstance::PrepareTextureMailbox(cc::TextureMailbox*) {
needs param name

https://chromiumcodereview.appspot.com/12374028/diff/43001/webkit/plugins/ppa...
File webkit/plugins/ppapi/ppapi_plugin_instance.h (right):

https://chromiumcodereview.appspot.com/12374028/diff/43001/webkit/plugins/ppa...
webkit/plugins/ppapi/ppapi_plugin_instance.h:468: virtual bool
PrepareTextureMailbox(cc::TextureMailbox*) OVERRIDE;
all parameters get a name in chromium style

[alexst (slow to review), 2013-04-11 18:03:11]

James, new patch.

https://chromiumcodereview.appspot.com/12374028/diff/43001/webkit/compositor_...
File webkit/compositor_bindings/web_external_texture_layer_impl.cc (right):

https://chromiumcodereview.appspot.com/12374028/diff/43001/webkit/compositor_...
webkit/compositor_bindings/web_external_texture_layer_impl.cc:127: const
WebKit::WebExternalTextureMailbox &mailbox,
On 2013/04/11 17:36:58, jamesr wrote:
> & goes with the type, not the variable name

Done.

https://chromiumcodereview.appspot.com/12374028/diff/43001/webkit/compositor_...
webkit/compositor_bindings/web_external_texture_layer_impl.cc:130: if
(lost_resource)
On 2013/04/11 17:36:58, jamesr wrote:
> why is the callback invoked with lost_resource=true if we're just ignoring it
in
> that case? do other callers need to do something here?

In this case, lost resources are already handled inside Blink. But for something
like browser plugin, we may still need to send an ACK even if the resource is
lost to not hang the guest renderer.

https://chromiumcodereview.appspot.com/12374028/diff/43001/webkit/compositor_...
File webkit/compositor_bindings/web_external_texture_layer_impl.h (right):

https://chromiumcodereview.appspot.com/12374028/diff/43001/webkit/compositor_...
webkit/compositor_bindings/web_external_texture_layer_impl.h:52: void
mailboxReleased(const WebKit::WebExternalTextureMailbox &mailbox,
On 2013/04/11 17:36:58, jamesr wrote:
> use Chromium naming style for functions that aren't implementing WebKit API. 
> This should be capitalized MailboxReleased(), although that's a bit of an
> awkward name for a function.  What is this function supposed to do?  React to
a
> mailbox being released?
> 
> Put the & with the type name (i.e. const WK::WETM& mailbox, not const WKMETM
> &callback)

Yes, it's called when a mailbox is no longer in use. How about OnMailboxReleased
instead?

https://chromiumcodereview.appspot.com/12374028/diff/43001/webkit/plugins/ppa...
File webkit/plugins/ppapi/ppapi_plugin_instance.cc (right):

https://chromiumcodereview.appspot.com/12374028/diff/43001/webkit/plugins/ppa...
webkit/plugins/ppapi/ppapi_plugin_instance.cc:2109: bool
PluginInstance::PrepareTextureMailbox(cc::TextureMailbox*) {
On 2013/04/11 17:36:58, jamesr wrote:
> needs param name

Done.

https://chromiumcodereview.appspot.com/12374028/diff/43001/webkit/plugins/ppa...
File webkit/plugins/ppapi/ppapi_plugin_instance.h (right):

https://chromiumcodereview.appspot.com/12374028/diff/43001/webkit/plugins/ppa...
webkit/plugins/ppapi/ppapi_plugin_instance.h:468: virtual bool
PrepareTextureMailbox(cc::TextureMailbox*) OVERRIDE;
On 2013/04/11 17:36:58, jamesr wrote:
> all parameters get a name in chromium style

Done.

[jamesr, 2013-04-11 18:11:15]

drop the out_s and lgtm.  OnMailboxReleased is OK, but I slightly prefer using
Did/Will prefixes instead 'On' to clarify whether the function happens before or
after the event in question. I think that'd make this DidReleaseMailbox

https://chromiumcodereview.appspot.com/12374028/diff/55001/webkit/compositor_...
File webkit/compositor_bindings/web_external_texture_layer_impl.h (right):

https://chromiumcodereview.appspot.com/12374028/diff/55001/webkit/compositor_...
webkit/compositor_bindings/web_external_texture_layer_impl.h:49: virtual bool
PrepareTextureMailbox(cc::TextureMailbox* out_mailbox) OVERRIDE;
I don't think the out_ prefix is necessary - in Chromium, pointer parameters are
pretty much always either out or inout parameters (since in parameters are
passed by value or const ref) and we typically avoid hungarian-style tags.

[alexst (slow to review), 2013-04-11 18:32:24]

> after the event in question. I think that'd make this DidReleaseMailbox
> 

I like it, changed.

[commit-bot: I haz the power, 2013-04-11 18:33:35]

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

[commit-bot: I haz the power, 2013-04-11 18:54:01]

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-04-11 19:00:51]

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

[commit-bot: I haz the power, 2013-04-11 19:28:36]

Sorry for I got bad news for ya.
Compile failed with a clobber build on linux_clang.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_clan...
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-04-11 21:32:15]

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

[commit-bot: I haz the power, 2013-04-12 00:26:03]

Change committed as 193807