cc: Add historgram for the number of render passes in an ubercomp delegated frame.

cc: Add historgram for the number of render passes in an ubercomp delegated frame.

R=piman,enne
BUG=152337
NOTRY=true

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

[danakj, 2012-12-03 20:27:50]

We don't have a delegating renderer yet, so I thought this should go in the
message Writer itself. WDYT?

[piman, 2012-12-03 20:30:22]

https://codereview.chromium.org/11419296/diff/3002/content/common/cc_messages.cc
File content/common/cc_messages.cc (right):

https://codereview.chromium.org/11419296/diff/3002/content/common/cc_messages...
content/common/cc_messages.cc:600: HISTOGRAM_COUNTS("Renderer4.renderPassCount",
frame.renderPasses.size());
I was thinking of adding this in the GLRenderer (or DirectRenderer), so that we
can get data now.

[danakj, 2012-12-03 20:31:41]

https://codereview.chromium.org/11419296/diff/3002/content/common/cc_messages.cc
File content/common/cc_messages.cc (right):

https://codereview.chromium.org/11419296/diff/3002/content/common/cc_messages...
content/common/cc_messages.cc:600: HISTOGRAM_COUNTS("Renderer4.renderPassCount",
frame.renderPasses.size());
On 2012/12/03 20:30:22, piman wrote:
> I was thinking of adding this in the GLRenderer (or DirectRenderer), so that
we
> can get data now.

Oh, I thought that too, then I realized we get more renderpasses for aura
browser UI than we get for web pages. But I guess for the values we're concerned
about aura won't be hitting them?

[jamesr, 2012-12-03 20:33:34]

I think it'd be pretty weird for IPC serialization to have side effects like
this, personally.

[danakj, 2012-12-03 20:41:12]

Ok, moved to DirectRenderer. PTAL

[piman, 2012-12-03 21:12:23]

lgtm

[commit-bot: I haz the power, 2012-12-03 21:15:23]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/danakj@chromium.org/11419296/5

[commit-bot: I haz the power, 2012-12-04 00:50:53]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/danakj@chromium.org/11419296/5

[commit-bot: I haz the power, 2012-12-04 00:53:01]

Change committed as 170854

[piman, 2012-12-04 08:44:19]

On Mon, Dec 3, 2012 at 12:31 PM, <danakj@chromium.org> wrote:

>
> https://codereview.chromium.**org/11419296/diff/3002/**
>
content/common/cc_messages.cc<https://codereview.chromium.org/11419296/diff/3002/content/common/cc_messages.cc>
> File content/common/cc_messages.cc (right):
>
> https://codereview.chromium.**org/11419296/diff/3002/**
>
content/common/cc_messages.cc#**newcode600<https://codereview.chromium.org/11419296/diff/3002/content/common/cc_messages.cc#newcode600>
> content/common/cc_messages.cc:**600:
> HISTOGRAM_COUNTS("Renderer4.**renderPassCount",
> frame.renderPasses.size());
> On 2012/12/03 20:30:22, piman wrote:
>
>> I was thinking of adding this in the GLRenderer (or DirectRenderer),
>>
> so that we
>
>> can get data now.
>>
>
> Oh, I thought that too, then I realized we get more renderpasses for
> aura browser UI than we get for web pages. But I guess for the values
> we're concerned about aura won't be hitting them?
>

Yeah, I'm not too worried about that. We may get a peak at an unexpected
value from Aura, and it's good to keep in mind as a sanity check, but I
don't think it would really skew the data.


>
>
https://codereview.chromium.**org/11419296/<https://codereview.chromium.org/1...
>