There are two possible causes for this:
1. If we're swap throttled and we haven't drawn and we are waiting for activation (i.e. the entire pipeline is full) we throttle BeginMainFrame to avoid deadlock for NPAPI - danakj@ was looking at removing this as part of NPAPI cleanup. https://code.google.com/p/chromium/codesearch#chromium/src/cc/scheduler/scheduler_state_machine.cc&l=414
2. If impl latency takes priority which is a combination of two things - the page should not have scroll handlers and smoothness takes priority is true. https://code.google.com/p/chromium/codesearch#chromium/src/cc/scheduler/scheduler_state_machine.cc&l=1030

Is it possible to tell which case it is from the trace?  I can run more tests.

Not from the one above. But we can get more information if you enable the cc.debug.scheduler tracing category.

Attached trace with cc.debug.scheduler enabled.

Deleted: trace_animometer_leaves_cc_debug_scheduler.json.zip 1.0 MB

trace_animometer_leaves_cc_debug_scheduler.json.zip 1.0 MB Download

My initial assessment was incorrect. This happens because the scheduler has a policy of not sending a begin main frame until activation. There's a flag --enable-main-frame-before-activation that allows changing this policy.

Using --enable-main-frame-before-activation gives a 20% improvement in the benchmark on my MBP.  Should we reconsider this policy for NEW_CONTENT_TAKES_PRIORITY cases?

btw this benchmark has SAME_PRIORITY_FOR_BOTH_TREES at least for the frames I looked at

I think the main frame before activation flag isn't enabled to reduce cpu contention especially for software raster. MBP has a lot of cpu so it just ends up hurting throughput. Testing this on android would be interesting.

It looks like a large win on Nexus 6P.  Without the flag we score in the range 46~56.  With the flag we score in the range 100~170.

The reason for the large variance appears to be thermal throttling.  When I put the 6P on an ice pack :-), we get a consistent score ~50 without the flag, ~160 with the flag.

I should mention, this flag makes Chrome a little unstable so it doesn't look ready to just turn on.

This probably makes sense if we're on a fast machine. The downside would be would be a higher peak CPU usage, power usage and possibly memory usage as well, right? I wonder what to use as a trigger (e.g., hw capabilities) for turning this on?

Looking for an owner to productize this 200% change :-)

This is mostly a cc::Scheduler thing - so I'll take it.

 Issue 419768  has been merged into this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8fe17485fab4a86d052d0dd783da779327e10fab

commit 8fe17485fab4a86d052d0dd783da779327e10fab
Author: sunnyps <sunnyps@chromium.org>
Date: Fri May 13 01:09:00 2016

cc: Remove throttling of main frames for preventing NPAPI deadlock.

Since NPAPI is no more this can go away.

BUG= 606210 
R=danakj@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Review-Url: https://codereview.chromium.org/1976823002
Cr-Commit-Position: refs/heads/master@{#393414}

[modify] https://crrev.com/8fe17485fab4a86d052d0dd783da779327e10fab/cc/scheduler/scheduler_state_machine.cc
[modify] https://crrev.com/8fe17485fab4a86d052d0dd783da779327e10fab/cc/scheduler/scheduler_state_machine.h
[modify] https://crrev.com/8fe17485fab4a86d052d0dd783da779327e10fab/cc/scheduler/scheduler_unittest.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b63f28f7aa471e911acd108c70b85b4a6c10e132

commit b63f28f7aa471e911acd108c70b85b4a6c10e132
Author: sunnyps <sunnyps@chromium.org>
Date: Mon May 16 21:50:35 2016

cc: Do not reset pending tree state incorrectly on aborted commits.

When the --enable-main-frame-before-activation flag is passed aborted
commits can cause the pending tree CHECK in LTHI::BeginCommit to fail.
This happens because the aborted commit resets the scheduler's pending
tree state and causes it to start a commit while there's a pending tree.

BUG= 606210 
R=enne@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Review-Url: https://codereview.chromium.org/1984453003
Cr-Commit-Position: refs/heads/master@{#393943}

[modify] https://crrev.com/b63f28f7aa471e911acd108c70b85b4a6c10e132/cc/scheduler/scheduler_state_machine.cc
[modify] https://crrev.com/b63f28f7aa471e911acd108c70b85b4a6c10e132/cc/scheduler/scheduler_state_machine_unittest.cc
[modify] https://crrev.com/b63f28f7aa471e911acd108c70b85b4a6c10e132/cc/trees/proxy_impl.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e85cf6b9adbf2f1ccfd6a9ea87c47cb186d549d6

commit e85cf6b9adbf2f1ccfd6a9ea87c47cb186d549d6
Author: sunnyps <sunnyps@chromium.org>
Date: Mon May 16 22:51:10 2016

cc: Fix cc_unittests when main frame before activation is enabled.

The LayerTreeHostAnimationTestScrollOffsetAnimationRemoval test
would time out because impl side would keep animating indefinitely. If
main frame before activation (MFBA) is enabled the test would keep
running because it waits for main frames to stop before ending.

A few scheduler state machine tests use the commit to active tree mode
which is incompatible with MFBA. One other test had to be modified to
remove unnecessary actions that would cause different behavior with
MFBA.

BUG= 606210 
R=enne@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Review-Url: https://codereview.chromium.org/1971063004
Cr-Commit-Position: refs/heads/master@{#393962}

[modify] https://crrev.com/e85cf6b9adbf2f1ccfd6a9ea87c47cb186d549d6/cc/scheduler/scheduler_state_machine_unittest.cc
[modify] https://crrev.com/e85cf6b9adbf2f1ccfd6a9ea87c47cb186d549d6/cc/trees/layer_tree_host_unittest_animation.cc

Closing this bug out because the issues with the flag have been fixed. Enabling this flag via a finch experiment is being tracked in  bug 612596 .