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

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


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

android-nexus7v2
android-nexus9

re-kicked bisect

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


===== SUSPECTED CL(s) =====
Subject : Hook up ui::Compositor to Display's BeginFrameSource
Author  : enne
Commit description:
  
This hooks up the first SurfaceFactoryClient to the real
BeginFrameSource owned by the OnScreenDisplayClient.  This is done by
adding an OutputSurfaceClient::SetBeginFrameSource method.  As the
SurfaceDisplayOutputSurface is also a SurfaceFactoryClient, it can hand
the real begin frame source directly to ui::Compositor's scheduler.

This allows the removal of some of the browser vsync plumbing, but not
all of it.  Once the renderer compositors have been hooked up to use
this path as well, then this and all of the VSyncObserver code can be
ripped out.

The BeginFrameSource is created by the BrowserCompositorOutputSurface
which updates it based on vsync information that it receives.  This
BeginFrameSource is passed to the Display (via OutputSurfaceClient),
which informs the SurfaceManager that the compositor using
that Display should be driven by that BeginFrameSource.  The
SurfaceManager then informs the SurfaceDisplayOutputSurface about
the BeginFrameSource, which passes it into the single thread proxy's
cc::Scheduler for that ui::Compositor's instance.  Plumbing!

The path from SurfaceManager to SurfaceDisplayOutputSurface was
added in https://codereview.chromium.org/1673783004, but the rest
of the plumbing is new to this patch.

CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Review URL: https://codereview.chromium.org/1821863002

Cr-Commit-Position: refs/heads/master@{#387228}
Commit  : 19c108580b99c469ed192066310e3162bf8c196e
Date    : Thu Apr 14 03:37:18 2016


===== TESTED REVISIONS =====
Revision                Mean Value  Std. Dev.   Num Values  Good?
chromium@385441         6.03082     0.229929    5           good
chromium@386433         6.39472     0.400905    5           good
chromium@386929         6.30598     0.385155    5           good
chromium@387177         6.3332      0.262791    5           good
chromium@387208         6.5224      0.291576    5           good
chromium@387224         6.2903      0.272105    5           good
chromium@387226         6.66154     0.557898    5           good
chromium@387227         6.5337      0.285533    5           good
chromium@387228         10.14226    0.63101     5           bad         <-
chromium@387232         9.98732     0.360211    5           bad
chromium@387239         10.39696    0.26559     5           bad
chromium@387301         9.9711      0.499416    5           bad
chromium@387424         9.74336     0.587291    5           bad

Bisect job ran on: android_nexus9_perf_bisect
Bug ID: 604366

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --also-run-disabled-tests smoothness.pathological_mobile_sites
Test Metric: mean_input_event_latency/mean_input_event_latency
Relative Change: 61.56%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus9_perf_bisect/builds/1758
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9014308459568210736


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

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