cc: CompositorTimingHistory throughput UMAs

cc: CompositorTimingHistory throughput UMAs

This adds the following metrics:

1) BeginMainFrameIntervalCritical:
     Commit rate, aborted or not, with the critical flag set.
2) BeginMainFrameIntervalNotCritical:
     Commit rate, aborted or not, without the critical flag set.
2) CommitInterval:
     Draw rate of new active trees.
3) DrawInterval:
     Draw rate of the compositor.

Each metric is only reported when
that stage is in a continually active
state.

BUG=477012
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/d32468dc9c5427126d519ac320167ffe77ecb7da
Cr-Commit-Position: refs/heads/master@{#361743}

[brianderson, 2015-11-19 00:32:44]

brianderson@chromium.org changed reviewers:
+ skyostil@chromium.org, sunnyps@chromium.org, tdresser@chromium.org

[brianderson, 2015-11-19 00:32:44]

What do y'all think about adding throughput metrics like this based on
timestamps we are already collecting at runtime for CompositorTimingHistory.

I'm thinking it will better help us understand tradeoffs when we get around to
running finch experiments.

(This patch depends on: https://codereview.chromium.org/1265023005/)

[Sami, 2015-11-19 15:37:40]

Tracking something like this seems useful to me. Just to make sure I understand:

Scheduling.Renderer.CommitInterval = "main thread frame rate"

Scheduling.Renderer.NewActiveTreeDrawInterval = "new content frame rate"

Scheduling.Renderer.DrawInterval = "static content frame rate"

?

I wonder if the first one should be split based on the critical path flag, or
maybe just report it when we're on the critical path?

https://codereview.chromium.org/1460923002/diff/1/cc/scheduler/scheduler_stat...
File cc/scheduler/scheduler_state_machine.h (right):

https://codereview.chromium.org/1460923002/diff/1/cc/scheduler/scheduler_stat...
cc/scheduler/scheduler_state_machine.h:104: bool NewActiveTreeLikely() const {
Should we somehow unify this with BeginMainFrameNotExpectedSoon or are they
separate concepts?

[brianderson, 2015-11-19 19:37:57]

On 2015/11/19 15:37:40, Sami wrote:
> Tracking something like this seems useful to me. Just to make sure I
understand:
> 
> Scheduling.Renderer.CommitInterval = "main thread frame rate"
> 
> Scheduling.Renderer.NewActiveTreeDrawInterval = "new content frame rate"
> 
> Scheduling.Renderer.DrawInterval = "static content frame rate"
> 
> ?

Your understanding is correct. Names of metrics definitely up for discussion.

> 
> I wonder if the first one should be split based on the critical path flag, or
> maybe just report it when we're on the critical path?

Yeah, I think that would make sense for the main thread frame rate.

> 
>
https://codereview.chromium.org/1460923002/diff/1/cc/scheduler/scheduler_stat...
> File cc/scheduler/scheduler_state_machine.h (right):
> 
>
https://codereview.chromium.org/1460923002/diff/1/cc/scheduler/scheduler_stat...
> cc/scheduler/scheduler_state_machine.h:104: bool NewActiveTreeLikely() const {
> Should we somehow unify this with BeginMainFrameNotExpectedSoon or are they
> separate concepts?

[brianderson, 2015-11-19 19:38:03]

https://codereview.chromium.org/1460923002/diff/1/cc/scheduler/scheduler_stat...
File cc/scheduler/scheduler_state_machine.h (right):

https://codereview.chromium.org/1460923002/diff/1/cc/scheduler/scheduler_stat...
cc/scheduler/scheduler_state_machine.h:104: bool NewActiveTreeLikely() const {
On 2015/11/19 15:37:40, Sami wrote:
> Should we somehow unify this with BeginMainFrameNotExpectedSoon or are they
> separate concepts?

The existing BeginMainFrameNotExpectedSoon has false negatives, which is good
for the long idle work, because we avoid punishing important frames.

Using NewActiveTreeLikely would have false positives - for example, when the
main thread is running on a 24hz timer instead of rAF. This is good for UMA data
collection because we discard frames that aren't going to be throughput bound.

So I think they should remain separate concepts. But I think we could improve
BeginMainFrameNotExpectedSoon, by making it look more like NewActiveTreeLikely,
but with more of a delay.

[brianderson, 2015-11-20 02:13:36]

Updated the names and also split the first one into critical/not critical.

[Sami, 2015-11-20 18:34:13]

lgtm, the new names make this easier to grok.

[brianderson, 2015-11-20 22:58:58]

brianderson@chromium.org changed reviewers:
+ isherman@chromium.org

[brianderson, 2015-11-20 22:58:59]

+isherman for owner's review of histograms.xml.

Note: Since Sami's stamp, I changed the naming of some internal variables in
CompositorTimingHistory to be more consistent.

[Ilya Sherman, 2015-11-20 23:41:51]

histograms lgtm

[brianderson, 2015-11-21 00:49:29]

+benjhaden as fyi.

[brianderson, 2015-11-23 23:45:52]

Description was changed from

==========
cc: CompositorTimingHistory throughput UMAs

This adds metrics for:
1) Commit rate (aborted or not).
2) Draw rate of new active trees.
3) Draw rate of updated active trees.

Each metric is only reported when
that stage is in a continually active
state. Given certain state, we can
anticipate a new frame will arrive
soon after the previous one.

BUG=
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
cc: CompositorTimingHistory throughput UMAs

This adds metrics for:
1) Commit rate (aborted or not).
2) Draw rate of new active trees.
3) Draw rate of updated active trees.

Each metric is only reported when
that stage is in a continually active
state. Given certain state, we can
anticipate a new frame will arrive
soon after the previous one.

BUG=477012
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[brianderson, 2015-11-23 23:57:22]

Description was changed from

==========
cc: CompositorTimingHistory throughput UMAs

This adds metrics for:
1) Commit rate (aborted or not).
2) Draw rate of new active trees.
3) Draw rate of updated active trees.

Each metric is only reported when
that stage is in a continually active
state. Given certain state, we can
anticipate a new frame will arrive
soon after the previous one.

BUG=477012
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
cc: CompositorTimingHistory throughput UMAs

This adds the following metrics:
1) BeginMainFrameIntervalCritical:
     Commit rate, aborted or not, with the critical flag set.
2) BeginMainFrameIntervalNotCritical:
     Commit rate, aborted or not, without the critical flag set.
2) CommitInterval:
     Draw rate of new active trees.
3) DrawInterval:
     Draw rate of the compositor.

Each metric is only reported when
that stage is in a continually active
state.

BUG=477012
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[brianderson, 2015-11-23 23:58:54]

Description was changed from

==========
cc: CompositorTimingHistory throughput UMAs

This adds the following metrics:
1) BeginMainFrameIntervalCritical:
     Commit rate, aborted or not, with the critical flag set.
2) BeginMainFrameIntervalNotCritical:
     Commit rate, aborted or not, without the critical flag set.
2) CommitInterval:
     Draw rate of new active trees.
3) DrawInterval:
     Draw rate of the compositor.

Each metric is only reported when
that stage is in a continually active
state.

BUG=477012
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
cc: CompositorTimingHistory throughput UMAs

This adds the following metrics:

1) BeginMainFrameIntervalCritical:
     Commit rate, aborted or not, with the critical flag set.
2) BeginMainFrameIntervalNotCritical:
     Commit rate, aborted or not, without the critical flag set.
2) CommitInterval:
     Draw rate of new active trees.
3) DrawInterval:
     Draw rate of the compositor.

Each metric is only reported when
that stage is in a continually active
state.

BUG=477012
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[brianderson, 2015-11-25 19:02:02]

Made a small change that helps detect that the main thread is active for cases
like animations that use ~setInterval(17).

[brianderson, 2015-11-25 19:02:26]

The CQ bit was checked by brianderson@chromium.org

[brianderson, 2015-11-25 19:02:26]

The patchset sent to the CQ was uploaded after l-g-t-m from
skyostil@chromium.org, isherman@chromium.org
Link to the patchset: https://codereview.chromium.org/1460923002/#ps80001
(title: "Support setInterval(17)")

[commit-bot: I haz the power, 2015-11-25 19:04:57]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1460923002/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1460923002/80001

[brianderson, 2015-11-25 19:08:13]

The CQ bit was unchecked by brianderson@chromium.org

[brianderson, 2015-11-25 19:09:33]

The CQ bit was checked by brianderson@chromium.org

[brianderson, 2015-11-25 19:09:33]

The patchset sent to the CQ was uploaded after l-g-t-m from
isherman@chromium.org, skyostil@chromium.org
Link to the patchset: https://codereview.chromium.org/1460923002/#ps100001
(title: "Remove debug TRACE_EVENTS")

[commit-bot: I haz the power, 2015-11-25 19:10:29]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1460923002/100001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1460923002/100001

[commit-bot: I haz the power, 2015-11-25 22:09:02]

Description was changed from

==========
cc: CompositorTimingHistory throughput UMAs

This adds the following metrics:

1) BeginMainFrameIntervalCritical:
     Commit rate, aborted or not, with the critical flag set.
2) BeginMainFrameIntervalNotCritical:
     Commit rate, aborted or not, without the critical flag set.
2) CommitInterval:
     Draw rate of new active trees.
3) DrawInterval:
     Draw rate of the compositor.

Each metric is only reported when
that stage is in a continually active
state.

BUG=477012
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
cc: CompositorTimingHistory throughput UMAs

This adds the following metrics:

1) BeginMainFrameIntervalCritical:
     Commit rate, aborted or not, with the critical flag set.
2) BeginMainFrameIntervalNotCritical:
     Commit rate, aborted or not, without the critical flag set.
2) CommitInterval:
     Draw rate of new active trees.
3) DrawInterval:
     Draw rate of the compositor.

Each metric is only reported when
that stage is in a continually active
state.

BUG=477012
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[commit-bot: I haz the power, 2015-11-25 22:09:04]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2015-11-25 22:10:52]

Description was changed from

==========
cc: CompositorTimingHistory throughput UMAs

This adds the following metrics:

1) BeginMainFrameIntervalCritical:
     Commit rate, aborted or not, with the critical flag set.
2) BeginMainFrameIntervalNotCritical:
     Commit rate, aborted or not, without the critical flag set.
2) CommitInterval:
     Draw rate of new active trees.
3) DrawInterval:
     Draw rate of the compositor.

Each metric is only reported when
that stage is in a continually active
state.

BUG=477012
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
cc: CompositorTimingHistory throughput UMAs

This adds the following metrics:

1) BeginMainFrameIntervalCritical:
     Commit rate, aborted or not, with the critical flag set.
2) BeginMainFrameIntervalNotCritical:
     Commit rate, aborted or not, without the critical flag set.
2) CommitInterval:
     Draw rate of new active trees.
3) DrawInterval:
     Draw rate of the compositor.

Each metric is only reported when
that stage is in a continually active
state.

BUG=477012
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/d32468dc9c5427126d519ac320167ffe77ecb7da
Cr-Commit-Position: refs/heads/master@{#361743}
==========

[commit-bot: I haz the power, 2015-11-25 22:10:53]

Patchset 6 (id:??) landed as
https://crrev.com/d32468dc9c5427126d519ac320167ffe77ecb7da
Cr-Commit-Position: refs/heads/master@{#361743}