cc: Add frame data to LTHI tracing

cc: Add frame data to LTHI tracing

This adds AddValue support to FrameData, RenderPass, *DrawQuad, FilterOperations, etc.
It also adds an optional 'frame' field to the LTHI state which is the frame
being produced at this point, with everything mentioned above.

BUG=None
R=danakj@chromium.org, nduca@chromium.org, vmpstr@chromium.org

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

[piman, 2013-07-26 06:28:43]

vmpstr: please review whole CL
danakj: please review comments added to DrawQuad/SharedQuadState about the
coordinate spaces.

Note: the FrameData is pretty exhaustive, though because it's dumped as a field
of the LTHI dump, we can't explore it directly until we add support in the
viewer.

[vmpstr, 2013-07-26 16:07:23]

That's quite a bit of data :) I think in general, we're trying to limit the
amount of information in the traces to something that is useful (ie someone
needs it or will definitely use it). Is it possible that for this patch we
eliminate some of the fields just to limit the trace size? For instance, there's
several quads that have some sort of resource id associated with them. I don't
think it would be very useful if we put that in a trace. What I mean to say is
that all we'll see is that there's a resource id and it's some integer, but
other than that it doesn't provide much useful information. I could be wrong, of
course.

I propose we put the bare minimum useful things (though this is very
subjective), and if something becomes valuable we can tack that on later. Wdyt?

https://codereview.chromium.org/20667002/diff/1/cc/output/filter_operation.cc
File cc/output/filter_operation.cc (right):

https://codereview.chromium.org/20667002/diff/1/cc/output/filter_operation.cc...
cc/output/filter_operation.cc:224: switch (type_) {
Can you add a default NOTREACHED() so that we catch any changes to the enums
(that a compiler might catch anyway)?

https://codereview.chromium.org/20667002/diff/1/cc/quads/draw_quad.cc
File cc/quads/draw_quad.cc (right):

https://codereview.chromium.org/20667002/diff/1/cc/quads/draw_quad.cc#newcode100
cc/quads/draw_quad.cc:100: value->Set("rect",
MathUtil::AsValue(rect).release());
Maybe the rects can be named something like "content_space_rect" or something to
indicate which space the rect is in. Alternatively they can just all be
transformed to target space before appending to value (which would also save
some calculations in the trace viewer).

https://codereview.chromium.org/20667002/diff/1/cc/quads/draw_quad.cc#newcode112
cc/quads/draw_quad.cc:112: value->SetBoolean("ShouldDrawWithBlending()",
ShouldDrawWithBlending());
should_draw_with_blending

[danakj, 2013-07-26 16:49:08]

+1 to vlad. If we can avoid the virtual function for now and just dump some
interesting things off the DrawQuad base struct, that'd be a good start.

https://codereview.chromium.org/20667002/diff/1/cc/output/filter_operation.cc
File cc/output/filter_operation.cc (right):

https://codereview.chromium.org/20667002/diff/1/cc/output/filter_operation.cc...
cc/output/filter_operation.cc:224: switch (type_) {
On 2013/07/26 16:07:23, vmpstr wrote:
> Can you add a default NOTREACHED() so that we catch any changes to the enums
> (that a compiler might catch anyway)?

Actually, I'd prefer to not have a 'default' case so that we get compiler
warnings when things are added to the enum without being added here.

Having a DCHECK() that at least 1 case was run would be fine though.

https://codereview.chromium.org/20667002/diff/1/cc/quads/draw_quad.cc
File cc/quads/draw_quad.cc (right):

https://codereview.chromium.org/20667002/diff/1/cc/quads/draw_quad.cc#newcode100
cc/quads/draw_quad.cc:100: value->Set("rect",
MathUtil::AsValue(rect).release());
On 2013/07/26 16:07:23, vmpstr wrote:
> Maybe the rects can be named something like "content_space_rect" or something
to
> indicate which space the rect is in. Alternatively they can just all be
> transformed to target space before appending to value (which would also save
> some calculations in the trace viewer).

Agree, content_rect is our typical nomenclature for such a thing.

[danakj, 2013-07-26 16:53:59]

https://codereview.chromium.org/20667002/diff/1/cc/trees/layer_tree_host_impl.cc
File cc/trees/layer_tree_host_impl.cc (right):

https://codereview.chromium.org/20667002/diff/1/cc/trees/layer_tree_host_impl...
cc/trees/layer_tree_host_impl.cc:435: value->Set("occluding_screen_space_rects",
occluding_list.release());
These 3 lists only exist when you are showing them in the hud, I don't think
it's worth dumping debug data like this.

https://codereview.chromium.org/20667002/diff/1/cc/trees/layer_tree_host_impl...
cc/trees/layer_tree_host_impl.cc:1254:
TracedValue::FromValue(AsValueWithFrame(frame).release()));
If frame->has_no_damage, you don't get here. Also if we checkerboard an
animation. I think you may want to dump this stuff in PrepareToDraw() so it
doesn't get missed by our early outs.

[nduca, 2013-07-26 23:03:20]

#define TRACE_EVENT_CATEGORY_GROUP_ENABLED(category_group, ret) if it helps

[piman, 2013-07-31 00:36:43]

PTAL

https://codereview.chromium.org/20667002/diff/1/cc/quads/draw_quad.cc
File cc/quads/draw_quad.cc (right):

https://codereview.chromium.org/20667002/diff/1/cc/quads/draw_quad.cc#newcode100
cc/quads/draw_quad.cc:100: value->Set("rect",
MathUtil::AsValue(rect).release());
On 2013/07/26 16:49:08, danakj wrote:
> On 2013/07/26 16:07:23, vmpstr wrote:
> > Maybe the rects can be named something like "content_space_rect" or
something
> to
> > indicate which space the rect is in. Alternatively they can just all be
> > transformed to target space before appending to value (which would also save
> > some calculations in the trace viewer).
> 
> Agree, content_rect is our typical nomenclature for such a thing.

Following our discussion, and the need to have a pre-transformed version, I
chose new names: rect_in_content_space and rect_as_target_space_quad (the latter
is a "quad", aka 4 points because a rect is axis-aligned, property that doesn't
necessarily survive the transform). Ditto for opaque_rect and visible_rect.

Note: I also left the original (content space) rect, in case we want to show
things like the ratio of opaque vs transparent or things like that. Intersecting
quads is certainly less fun than intersecting axis-aligned rects.

https://codereview.chromium.org/20667002/diff/1/cc/quads/draw_quad.cc#newcode112
cc/quads/draw_quad.cc:112: value->SetBoolean("ShouldDrawWithBlending()",
ShouldDrawWithBlending());
On 2013/07/26 16:07:23, vmpstr wrote:
> should_draw_with_blending

Done.

https://codereview.chromium.org/20667002/diff/1/cc/trees/layer_tree_host_impl.cc
File cc/trees/layer_tree_host_impl.cc (right):

https://codereview.chromium.org/20667002/diff/1/cc/trees/layer_tree_host_impl...
cc/trees/layer_tree_host_impl.cc:435: value->Set("occluding_screen_space_rects",
occluding_list.release());
On 2013/07/26 16:53:59, danakj wrote:
> These 3 lists only exist when you are showing them in the hud, I don't think
> it's worth dumping debug data like this.

Removed those (2) lists.

https://codereview.chromium.org/20667002/diff/1/cc/trees/layer_tree_host_impl...
cc/trees/layer_tree_host_impl.cc:1254:
TracedValue::FromValue(AsValueWithFrame(frame).release()));
On 2013/07/26 16:53:59, danakj wrote:
> If frame->has_no_damage, you don't get here. Also if we checkerboard an
> animation. I think you may want to dump this stuff in PrepareToDraw() so it
> doesn't get missed by our early outs.

For 2 reasons we want to leave it here:
1- we want to associate the frame with the LTHI state, so that we can show it in
the UI
2- we didn't want to add a separate track, and we can't have different types of
data in the same track

I raised your point and Nat agreed that we may want to dump the FrameData,
separately, when we don't draw, but as a separate category, and in a follow-up.

https://codereview.chromium.org/20667002/diff/20002/cc/quads/render_pass.cc
File cc/quads/render_pass.cc (right):

https://codereview.chromium.org/20667002/diff/20002/cc/quads/render_pass.cc#n...
cc/quads/render_pass.cc:22: return reinterpret_cast<void*>(hash(layer_id,
index));
Note: nothing ensures that this won't collide with pointers (that other classes
use as an ID), but when I need to refer to the RenderPass in the quad, the
RenderPass::Id is all I have, I don't have the RenderPass pointer itself. I
don't know if there's a better solution?

https://codereview.chromium.org/20667002/diff/20002/cc/quads/render_pass.cc#n...
cc/quads/render_pass.cc:41:
TRACE_EVENT_OBJECT_DELETED_WITH_ID(TRACE_DISABLED_BY_DEFAULT("cc.debug"),
I find this a bit awkward... The snapshot is associated with the category where
it is first taken, and the UI complains if we don't delete it from the same
category. But it means that the FrameData can't be dumped from another category
at the same time if we wanted to do that...

[piman, 2013-07-31 00:49:40]

https://codereview.chromium.org/20667002/diff/20002/cc/quads/render_pass.cc
File cc/quads/render_pass.cc (right):

https://codereview.chromium.org/20667002/diff/20002/cc/quads/render_pass.cc#n...
cc/quads/render_pass.cc:17: BASE_HASH_NAMESPACE::hash<std::pair<Type1, Type2> >
hash_functor;
Ah, hold on, this doesn't work on MSVC, I'll have to extract the hash function
more properly.

[vmpstr, 2013-07-31 16:23:24]

https://codereview.chromium.org/20667002/diff/20002/cc/quads/draw_quad.cc
File cc/quads/draw_quad.cc (right):

https://codereview.chromium.org/20667002/diff/20002/cc/quads/draw_quad.cc#new...
cc/quads/draw_quad.cc:103: value->Set("rect_in_content_space",
MathUtil::AsValue(rect).release());
nit: A little note for the future (or maybe for here): if you name the variables
ending with _rect, then the tracing importer will do some work for us and
convert it from an array to a rect (and same for _quad). So, content_space_rect
would probably be a bit better, but trying to name every rect ending with _rect
might make naming awkward.

https://codereview.chromium.org/20667002/diff/20002/cc/quads/render_pass.cc
File cc/quads/render_pass.cc (right):

https://codereview.chromium.org/20667002/diff/20002/cc/quads/render_pass.cc#n...
cc/quads/render_pass.cc:22: return reinterpret_cast<void*>(hash(layer_id,
index));
On 2013/07/31 00:36:43, piman wrote:
> Note: nothing ensures that this won't collide with pointers (that other
classes
> use as an ID), but when I need to refer to the RenderPass in the quad, the
> RenderPass::Id is all I have, I don't have the RenderPass pointer itself. I
> don't know if there's a better solution?

I think that's fine, but Nat might say otherwise? :) As an aside, I think we
should support any numeric type as a tracing id, not just a void*, but that's
unrelated to this patch.

[piman, 2013-08-06 04:19:32]

Rebased on top of https://codereview.chromium.org/21648002/ to clean up the hash
business.

https://codereview.chromium.org/20667002/diff/20002/cc/quads/draw_quad.cc
File cc/quads/draw_quad.cc (right):

https://codereview.chromium.org/20667002/diff/20002/cc/quads/draw_quad.cc#new...
cc/quads/draw_quad.cc:103: value->Set("rect_in_content_space",
MathUtil::AsValue(rect).release());
On 2013/07/31 16:23:25, vmpstr wrote:
> nit: A little note for the future (or maybe for here): if you name the
variables
> ending with _rect, then the tracing importer will do some work for us and
> convert it from an array to a rect (and same for _quad). So,
content_space_rect
> would probably be a bit better, but trying to name every rect ending with
_rect
> might make naming awkward.

It did it that way, I think the names work.

[vmpstr, 2013-08-06 16:43:43]

lgtm. Do you have a sample trace from this code somewhere? We should check that
into trace-viewer so we have a reference (pending any other comments, of
course).

[danakj, 2013-08-06 19:30:34]

https://codereview.chromium.org/20667002/diff/43001/cc/quads/draw_quad.cc
File cc/quads/draw_quad.cc (right):

https://codereview.chromium.org/20667002/diff/43001/cc/quads/draw_quad.cc#new...
cc/quads/draw_quad.cc:105: gfx::QuadF rect_as_target_space_quad =
MathUtil::MapQuad(
How about MapClippedQuad instead? You can't just ignore the clipped return
value, it's not allowed, and that way you don't need to worry about it.

https://codereview.chromium.org/20667002/diff/43001/cc/quads/draw_quad.cc#new...
cc/quads/draw_quad.cc:114: gfx::QuadF opaque_rect_as_target_space_quad =
MathUtil::MapQuad(
same

https://codereview.chromium.org/20667002/diff/43001/cc/quads/draw_quad.cc#new...
cc/quads/draw_quad.cc:123: gfx::QuadF visible_rect_as_target_space_quad =
MathUtil::MapQuad(
same

https://codereview.chromium.org/20667002/diff/43001/cc/quads/io_surface_draw_...
File cc/quads/io_surface_draw_quad.cc (right):

https://codereview.chromium.org/20667002/diff/43001/cc/quads/io_surface_draw_...
cc/quads/io_surface_draw_quad.cc:67: orientation == FLIPPED ? "flipped" :
"unflipped");
Can you use switch here so we get compiler error when the enum changes? Best
practice and all.. as unlikely as we are to see the enum change.

https://codereview.chromium.org/20667002/diff/43001/cc/quads/render_pass.cc
File cc/quads/render_pass.cc (right):

https://codereview.chromium.org/20667002/diff/43001/cc/quads/render_pass.cc#n...
cc/quads/render_pass.cc:17: return
reinterpret_cast<void*>(base::HashPair(layer_id, index));
can sizeof(size_t) be > sizeof(void*) ?

https://codereview.chromium.org/20667002/diff/43001/cc/quads/shared_quad_stat...
File cc/quads/shared_quad_state.cc (right):

https://codereview.chromium.org/20667002/diff/43001/cc/quads/shared_quad_stat...
cc/quads/shared_quad_state.cc:62: TracedValue::MakeDictIntoImplicitSnapshot(
Why do you do this for RenderPass and SQState, but not for DrawQuad and not for
FrameData? (I don't really understand what this is for.)

[piman, 2013-08-06 23:31:11]

https://codereview.chromium.org/20667002/diff/43001/cc/quads/draw_quad.cc
File cc/quads/draw_quad.cc (right):

https://codereview.chromium.org/20667002/diff/43001/cc/quads/draw_quad.cc#new...
cc/quads/draw_quad.cc:105: gfx::QuadF rect_as_target_space_quad =
MathUtil::MapQuad(
On 2013/08/06 19:30:34, danakj wrote:
> How about MapClippedQuad instead? You can't just ignore the clipped return
> value, it's not allowed, and that way you don't need to worry about it.

The goal is to present something useful for the tracing UI. Talking to vmpstr@
who's going to implement it, at least in the short term, it's more useful to
have a quad than (potentially up to) 8 points. Given that w<=0 clipping would
only happen for 3D css, and only in rare cases (needs perspective transform and
a quad that actually goes behind the viewer), we deemed that having a "this rect
may not be valid" bit is more useful. We have the original rect and transform
anyway.

https://codereview.chromium.org/20667002/diff/43001/cc/quads/io_surface_draw_...
File cc/quads/io_surface_draw_quad.cc (right):

https://codereview.chromium.org/20667002/diff/43001/cc/quads/io_surface_draw_...
cc/quads/io_surface_draw_quad.cc:67: orientation == FLIPPED ? "flipped" :
"unflipped");
On 2013/08/06 19:30:34, danakj wrote:
> Can you use switch here so we get compiler error when the enum changes? Best
> practice and all.. as unlikely as we are to see the enum change.

Done.

https://codereview.chromium.org/20667002/diff/43001/cc/quads/render_pass.cc
File cc/quads/render_pass.cc (right):

https://codereview.chromium.org/20667002/diff/43001/cc/quads/render_pass.cc#n...
cc/quads/render_pass.cc:17: return
reinterpret_cast<void*>(base::HashPair(layer_id, index));
On 2013/08/06 19:30:34, danakj wrote:
> can sizeof(size_t) be > sizeof(void*) ?

In theory, yes.
In practice, size_t has to be the same size as ptrdiff_t (though unsigned), and
in our flat address spaces, that's effectively the size of a pointer.
I added a COMPILE_ASSERT.

https://codereview.chromium.org/20667002/diff/43001/cc/quads/shared_quad_stat...
File cc/quads/shared_quad_state.cc (right):

https://codereview.chromium.org/20667002/diff/43001/cc/quads/shared_quad_stat...
cc/quads/shared_quad_state.cc:62: TracedValue::MakeDictIntoImplicitSnapshot(
On 2013/08/06 19:30:34, danakj wrote:
> Why do you do this for RenderPass and SQState, but not for DrawQuad and not
for
> FrameData? (I don't really understand what this is for.)

This lets us reference the data by ID.
Because RenderPasses are referenced through multiple ways (from the render pass
list and from the RenderPassDrawQuads), as well as SharedQuadStates (from the
various quads), this lets us reflect the DAG nature of the original data. See
also the TracedValue::CreateIDRef callsites.
It's not needed for DrawQuad or FrameData though.

[danakj, 2013-08-06 23:35:47]

https://codereview.chromium.org/20667002/diff/43001/cc/quads/draw_quad.cc
File cc/quads/draw_quad.cc (right):

https://codereview.chromium.org/20667002/diff/43001/cc/quads/draw_quad.cc#new...
cc/quads/draw_quad.cc:105: gfx::QuadF rect_as_target_space_quad =
MathUtil::MapQuad(
On 2013/08/06 23:31:11, piman wrote:
> On 2013/08/06 19:30:34, danakj wrote:
> > How about MapClippedQuad instead? You can't just ignore the clipped return
> > value, it's not allowed, and that way you don't need to worry about it.
> 
> The goal is to present something useful for the tracing UI. Talking to vmpstr@
> who's going to implement it, at least in the short term, it's more useful to
> have a quad than (potentially up to) 8 points. Given that w<=0 clipping would
> only happen for 3D css, and only in rare cases (needs perspective transform
and
> a quad that actually goes behind the viewer), we deemed that having a "this
rect
> may not be valid" bit is more useful. We have the original rect and transform
> anyway.

Oh, I forgot that it doesn't return a Quad, but a set of vertices, and MathUtil
has no method to get you the bounding quad back, only a bounding rect. Bleh, ok
sgtm. Can you output the clipped boolean too?

[piman, 2013-08-06 23:37:43]

https://codereview.chromium.org/20667002/diff/43001/cc/quads/draw_quad.cc
File cc/quads/draw_quad.cc (right):

https://codereview.chromium.org/20667002/diff/43001/cc/quads/draw_quad.cc#new...
cc/quads/draw_quad.cc:105: gfx::QuadF rect_as_target_space_quad =
MathUtil::MapQuad(
On 2013/08/06 23:35:47, danakj wrote:
> On 2013/08/06 23:31:11, piman wrote:
> > On 2013/08/06 19:30:34, danakj wrote:
> > > How about MapClippedQuad instead? You can't just ignore the clipped return
> > > value, it's not allowed, and that way you don't need to worry about it.
> > 
> > The goal is to present something useful for the tracing UI. Talking to
vmpstr@
> > who's going to implement it, at least in the short term, it's more useful to
> > have a quad than (potentially up to) 8 points. Given that w<=0 clipping
would
> > only happen for 3D css, and only in rare cases (needs perspective transform
> and
> > a quad that actually goes behind the viewer), we deemed that having a "this
> rect
> > may not be valid" bit is more useful. We have the original rect and
transform
> > anyway.
> 
> Oh, I forgot that it doesn't return a Quad, but a set of vertices, and
MathUtil
> has no method to get you the bounding quad back, only a bounding rect. Bleh,
ok
> sgtm. Can you output the clipped boolean too?

I do in the latest patch.

[danakj, 2013-08-06 23:39:27]

Yay, LGTM

https://codereview.chromium.org/20667002/diff/52001/cc/quads/draw_quad.cc
File cc/quads/draw_quad.cc (right):

https://codereview.chromium.org/20667002/diff/52001/cc/quads/draw_quad.cc#new...
cc/quads/draw_quad.cc:101:
TracedValue::CreateIDRef(shared_quad_state).release());
Oh I see, so this is so that you don't have to AsValue() the SQS here.

[nduca, 2013-08-07 22:11:53]

lgtm for what its worth maybe try that cat thing

https://codereview.chromium.org/20667002/diff/52001/cc/trees/layer_tree_host_...
File cc/trees/layer_tree_host_impl.cc (right):

https://codereview.chromium.org/20667002/diff/52001/cc/trees/layer_tree_host_...
cc/trees/layer_tree_host_impl.cc:1280: TRACE_DISABLED_BY_DEFAULT("cc.debug"),
"cc::LayerTreeHostImpl", this,
cc.debug,cc.debug.quads

[piman, 2013-08-09 04:18:19]

Nat: PTAL, I did the "cat" thing, it was happy with tot trace-viewer.

I suppose it needs trace-viewer r843 to roll first (hasn't yet I think).

If this looks fine, I can produce a trace with this data so that we can start
working on the viewer for it.

https://codereview.chromium.org/20667002/diff/52001/cc/trees/layer_tree_host_...
File cc/trees/layer_tree_host_impl.cc (right):

https://codereview.chromium.org/20667002/diff/52001/cc/trees/layer_tree_host_...
cc/trees/layer_tree_host_impl.cc:1280: TRACE_DISABLED_BY_DEFAULT("cc.debug"),
"cc::LayerTreeHostImpl", this,
On 2013/08/07 22:11:54, nduca wrote:
> cc.debug,cc.debug.quads

I tried it, but it didn't seem to do the right thing.
I ended up with "cc.debug.quads" both on the left (enabled by default) and the
right (disabled by default), but select any combination of them without
"cc.debug" wouldn't produce the trace.

I think this is enough: you have to select cc.debug to get the frames. If you
want the quads with that, you select cc.debug.quads.

[nduca, 2013-08-09 04:27:45]

lgtm with a few nits...

https://codereview.chromium.org/20667002/diff/64001/cc/debug/traced_value.h
File cc/debug/traced_value.h (right):

https://codereview.chromium.org/20667002/diff/64001/cc/debug/traced_value.h#n...
cc/debug/traced_value.h:22: static void MakeDictIntoImplicitSnapshot(const char*
category,
lets make this optional with overloading?

otherwise we're putting a ton of extra bytes on every object. its only needed
when they disagree right?

https://codereview.chromium.org/20667002/diff/64001/cc/trees/layer_tree_host_...
File cc/trees/layer_tree_host_impl.cc (right):

https://codereview.chromium.org/20667002/diff/64001/cc/trees/layer_tree_host_...
cc/trees/layer_tree_host_impl.cc:1280: TRACE_DISABLED_BY_DEFAULT("cc.debug"),
"cc::LayerTreeHostImpl", this,
i think you need this to be
TRACE_DISABLED_BY_DEFAULT("cc.debug") # "," #
TRACE_DISABLED_BY_DEFAULT("cc.debug.quads")

Otherwise if the user checks quads but not cc.debug it wont dump anything
useful...

[piman, 2013-08-09 20:26:06]

https://codereview.chromium.org/20667002/diff/64001/cc/debug/traced_value.h
File cc/debug/traced_value.h (right):

https://codereview.chromium.org/20667002/diff/64001/cc/debug/traced_value.h#n...
cc/debug/traced_value.h:22: static void MakeDictIntoImplicitSnapshot(const char*
category,
On 2013/08/09 04:27:45, nduca wrote:
> lets make this optional with overloading?
> 
> otherwise we're putting a ton of extra bytes on every object. its only needed
> when they disagree right?

Done.

I'd argue that at the callsite you can't know whether they disagree or not, but
I don't particularly care if you like it better this way :)

https://codereview.chromium.org/20667002/diff/64001/cc/trees/layer_tree_host_...
File cc/trees/layer_tree_host_impl.cc (right):

https://codereview.chromium.org/20667002/diff/64001/cc/trees/layer_tree_host_...
cc/trees/layer_tree_host_impl.cc:1280: TRACE_DISABLED_BY_DEFAULT("cc.debug"),
"cc::LayerTreeHostImpl", this,
On 2013/08/09 04:27:45, nduca wrote:
> i think you need this to be
> TRACE_DISABLED_BY_DEFAULT("cc.debug") # "," #
> TRACE_DISABLED_BY_DEFAULT("cc.debug.quads")
> 
> Otherwise if the user checks quads but not cc.debug it wont dump anything
> useful...

Ok, done.

[nduca, 2013-08-09 20:27:19]

Fair point.

Bombs awaaay!! :)

[commit-bot: I haz the power, 2013-08-09 20:59:36]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/piman@chromium.org/20667002/77001

[piman, 2013-08-09 21:26:00]

Sample data in trace-viewer@r852

[commit-bot: I haz the power, 2013-08-09 23:47:41]

Step "update" is always a major failure.
Look at the try server FAQ for more details.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...

[piman, 2013-08-09 23:51:27]

Committed patchset #11 manually as r216782 (presubmit successful).