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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgopPY6woM


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

chromium-rel-mac10

=== 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 : Revert of Turn on enable begin frame scheduling by default (patchset #11 id:200001 of https://codereview.chromium.org/1939253002/ )
Author  : enne
Commit description:
  
Reason for revert:
Causes smoothness regressions, other bugs

BUG= 623174 , 623467 , 623490 

Original issue's description:
> Turn on enable begin frame scheduling by default
>
> 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
>
> Committed: https://crrev.com/f2d7f5e1891703ec4384ededd80f896816921204
> Cr-Commit-Position: refs/heads/master@{#401796}

TBR=boliu@chromium.org,piman@chromium.org,skyostil@chromium.org,sunnyps@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.

Review-Url: https://codereview.chromium.org/2100203002
Cr-Commit-Position: refs/heads/master@{#402294}
Commit  : 7ea3a9cd847d7478598d22804d04c32c156c14f4
Date    : Mon Jun 27 21:40:33 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev    N  Good?
chromium@402276  3.05076  0.0931753  5  good
chromium@402286  3.13855  0.146615   5  good
chromium@402291  3.06014  0.07888    8  good
chromium@402293  3.15121  0.331553   8  good
chromium@402294  3.92045  0.351848   8  bad    <--
chromium@402295  4.05841  0.443795   8  bad

Bisect job ran on: mac_10_10_perf_bisect
Bug ID: 624245

Test Command: src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --also-run-disabled-tests memory.long_running_idle_gmail_background_tbmv2
Test Metric: Idle-v8-gc-scavenger_avg/Idle-v8-gc-scavenger_avg
Relative Change: 26.61%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/mac_10_10_perf_bisect/builds/2173
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9008557053276711872


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

| 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!

On this graph, it does look like turning on --enable-begin-frame-scheduling at r401796 and reverting at r401796 did affect this graph.  I'm not sure why this would be, or what this test represents.  CCing some folks who might know more.

Marking this as wontfix as this is regression is from a revert of something I plan to land eventually.

Er, that's reverting at r402294