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

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


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

chromium-rel-mac11

=== 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@401785  13.3275  0.00210163  5  good
chromium@401795  13.3281  0.00111804  5  good
chromium@401796  16.7031  0.0266254   5  bad    <--
chromium@401797  16.7211  0.0400622   5  bad
chromium@401798  16.7024  0.00645526  5  bad
chromium@401800  16.7065  0.0263757   5  bad
chromium@401805  16.7018  0.0272317   5  bad

Bisect job ran on: mac_10_11_perf_bisect
Bug ID: 623174

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

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/mac_10_11_perf_bisect/builds/689
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9008941637848486640


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

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

Some of the frame_time regressions look bogus, especially for Mac. They go from 13ms (lies!) to ~16ms (probably not a lie).

It'll be interesting to see if any of the wins from:
https://chromeperf.appspot.com/group_report?rev=401796

will become losses with the revert.

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

commit 7ea3a9cd847d7478598d22804d04c32c156c14f4
Author: enne <enne@chromium.org>
Date: Mon Jun 27 21:38:43 2016

Revert of Turn on enable begin frame scheduling by default (patchset #11 id:200001 of https://codereview.chromium.org/1939253002/ )

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}

[modify] https://crrev.com/7ea3a9cd847d7478598d22804d04c32c156c14f4/android_webview/lib/main/aw_main_delegate.cc
[modify] https://crrev.com/7ea3a9cd847d7478598d22804d04c32c156c14f4/cc/base/switches.cc
[modify] https://crrev.com/7ea3a9cd847d7478598d22804d04c32c156c14f4/cc/base/switches.h
[modify] https://crrev.com/7ea3a9cd847d7478598d22804d04c32c156c14f4/chrome/browser/chromeos/login/chrome_restart_request.cc
[modify] https://crrev.com/7ea3a9cd847d7478598d22804d04c32c156c14f4/content/browser/android/content_startup_flags.cc
[modify] https://crrev.com/7ea3a9cd847d7478598d22804d04c32c156c14f4/content/browser/compositor/browser_compositor_output_surface.cc
[modify] https://crrev.com/7ea3a9cd847d7478598d22804d04c32c156c14f4/content/browser/renderer_host/render_process_host_impl.cc
[modify] https://crrev.com/7ea3a9cd847d7478598d22804d04c32c156c14f4/content/renderer/gpu/render_widget_compositor.cc
[modify] https://crrev.com/7ea3a9cd847d7478598d22804d04c32c156c14f4/ui/compositor/compositor.cc

Moving this nonessential bug to the next milestone.

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

enne@, have you made any progress here?

Looks like a bunch of these metrics have recovered, should this be marked WontFix?

I reverted the original patch, but plan on relanding it.  I've investigated most of these and think they're mostly WontFix but I haven't finished looking through them all.  This bug can be marked Fixed in the meantime.