All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=623172

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgop6EpQkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgwv6UsQoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgwo-RsgoM


Bot(s) for this bug's original alert(s):

chromium-rel-win7-x64-dual
chromium-rel-win8-dual

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Mustaq, can you follow up on this?

From the instructions (https://chromium.googlesource.com/chromium/src/+/master/tools/perf/docs/perf_regression_sheriffing.md):
"After your shift, please try to follow up on the bugs you filed weekly. Kick off new bisects if the previous ones failed, and if the bisect picks a likely culprit follow up to ensure the CL author addresses the problem. If you are certain that a specific CL caused a performance regression, and the author does not have an immediate plan to address the problem, please revert the CL."

Started 2 bisects, removed 2 recovered alerts.

Bisect results from https://chromeperf.appspot.com/group_report?bug_id=623172

chromium@401795 0.0292012 0.00126471 5 good 
chromium@401797 0.0399616 0.000798144 5 bad

401797 was a change for Arc++, so suspicious CL is 401796.

https://codereview.chromium.org/1939253002

It looks possible this change affect performance.

enne@ Can you check if this regression is reasonable and acceptable?

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/9004056583992893056

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/9004056578442659904

===== BISECT JOB RESULTS =====
Status: completed


=== Bisection aborted ===
The bisect was aborted because The metric values for the initial "good" and "bad" revisions do not represent a clear regression.
Please contact the the team (see below) if you believe this is in error.

=== Warnings ===
The following warnings were raised by the bisect job:

 * Bisect failed to reproduce the regression with enough confidence.

===== TESTED REVISIONS =====
Revision         Mean     Std Dev    N   Good?
chromium@401755  24.6165  0.105888   12  good
chromium@401809  24.6086  0.0790461  18  bad

Bisect job ran on: win_8_perf_bisect
Bug ID: 623172

Test Command: src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --also-run-disabled-tests smoothness.tough_canvas_cases
Test Metric: frame_times/frame_times
Relative Change: 0.06%
Score: 0

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/win_8_perf_bisect/builds/2120
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9004056583992893056


Not what you expected? We'll investigate and get back to you!
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5846919264337920

| O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq
|  X  | for more information addressing perf regression bugs. For feedback,
| / \ | file a bug with component Tests>AutoBisect.  Thank you!

=== Auto-CCing suspected CL author enne@chromium.org ===

Hi enne@chromium.org, the bisect results pointed to your CL below as possibly
causing a regression. Please have a look at this info and see whether
your CL be related.


===== BISECT JOB RESULTS =====
Status: completed


===== SUSPECTED CL(s) =====
Subject : Turn on enable begin frame scheduling by default
Author  : enne
Commit description:
  
This turns on --enable-begin-frame-scheduling[1] for all[2] platforms.
This was already on for Android so should only be a real change
for desktop / ChromeOS platforms.

Lots of cleanup can follow from this like removing all commit vsync /
authoritative vsync / CompositorVSyncManager things, but this is a
smaller patch to suss out any performance regressions.

[1] In this case, "begin frame scheduling" means browser->renderer
begin frame ticks instead of sending vsync information and having
a synthetic source on the renderer side.

[2] MUS is not hooked up to begin frame scheduling yet, but
mojo:mash_session in an "oxygen" build still works with this patch
applied.  Blimp also doesn't use begin frame scheduling and will
eventually just be transitioned to a synthetic begin frame source
for its engine half.

CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Review-Url: https://codereview.chromium.org/1939253002
Cr-Commit-Position: refs/heads/master@{#401796}
Commit  : f2d7f5e1891703ec4384ededd80f896816921204
Date    : Fri Jun 24 02:43:08 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev    N  Good?
chromium@401755  20.982   0.0544214  5  good
chromium@401784  20.964   0.0620278  5  good
chromium@401791  20.99    0.0717023  5  good
chromium@401795  21.0712  0.126081   5  good
chromium@401796  21.6423  0.0699249  5  bad    <--
chromium@401797  21.6435  0.147397   5  bad
chromium@401798  21.6673  0.0911509  5  bad
chromium@401811  21.8216  0.0516094  5  bad

Bisect job ran on: win_x64_perf_bisect
Bug ID: 623172

Test Command: src/tools/perf/run_benchmark -v --browser=release_x64 --output-format=chartjson --upload-results --also-run-disabled-tests smoothness.tough_canvas_cases
Test Metric: frame_times/frame_times
Relative Change: 4.00%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/win_x64_perf_bisect/builds/1408
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9004056578442659904


Not what you expected? We'll investigate and get back to you!
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5798632826077184

| O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq
|  X  | for more information addressing perf regression bugs. For feedback,
| / \ | file a bug with component Tests>AutoBisect.  Thank you!

Perf sheriff ping

enne@, have you had a chance to look into this? It looks like several of the metrics still haven't recovered.

It is expected that in some cases where the browser was busy, frame times would slightly increase.  It's also the case that in a number of tests frame times got "more real" and so would get bigger if they were previously being delivered unreasonably fast.

https://docs.google.com/document/d/1aTaqW0yJj5C-9uTdkiQ7U6bCtBg6hdskzZcNOYrhTr8/view is the analysis I did when landing this for the first time.

It also appears that most of these metrics have recovered.