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

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


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

android-nexus5X

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

=== BISECT JOB RESULTS ===
NO Perf regression found

Bisect Details
  Configuration: android_nexus5X_perf_bisect
  Benchmark    : scheduler.tough_scheduling_cases
  Metric       : mean_input_event_latency/mean_input_event_latency

Revision             Result                  N
chromium@441886      13.0562 +- 141.065      168      good
chromium@441920      14.9059 +- 152.998      168      bad

To Run This Test
  src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests scheduler.tough_scheduling_cases

Debug Info
  https://chromeperf.appspot.com/buildbucket_job_status/8990905979373581888

Is this bisect wrong?
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5872749840433152


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

There are wide variances on the samples of the bisect bot. Is there a way I could get graphs for the individual test runs to see a breakdown of what's going on? I think this is bot related.

Looks a lot like  crbug.com/669608 , blocking on that.

+dtu for the graph question.

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

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

Hi haraken@chromium.org, the bisect results pointed to your CL, please take a look at the
results.


=== BISECT JOB RESULTS ===
Perf regression found with culprit

Suspected Commit
  Author : haraken
  Commit : 40458d4dd913d5fd6f4f1bb2da083a8a7136a9af
  Date   : Fri Jan 06 07:09:44 2017
  Subject: Remove ScriptController::initializeMainWorld

Bisect Details
  Configuration: android_nexus5X_perf_bisect
  Benchmark    : scheduler.tough_scheduling_cases
  Metric       : mean_input_event_latency/mean_input_event_latency
  Change       : 14.11% | 12.7056269841 -> 14.49875

Revision             Result                   N
chromium@441886      12.7056 +- 1.83994       9       good
chromium@441895      12.7264 +- 2.27218       13      good
chromium@441896      14.5301 +- 1.46325       6       bad       <--
chromium@441897      14.1988 +- 1.77583       6       bad
chromium@441900      14.9311 +- 0.839912      6       bad
chromium@441904      13.8479 +- 2.40595       9       bad
chromium@441920      14.4987 +- 1.77853       6       bad

To Run This Test
  src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests scheduler.tough_scheduling_cases

Debug Info
  https://chromeperf.appspot.com/buildbucket_job_status/8990641821358491520

Is this bisect wrong?
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5314916937891840


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

This bug has an owner, but was in a state that our triage picked up. Marking as Assigned.

haraken@: have you had a chance to look at this? You patch seems to introduce additional work. No?

+benchmark owner (brianderson@)

Comparing the traces of a good run vs a bad run, it looks like the scroll gestures are sometimes starting sooner after haraken's patch, while the GPU service is still busy. The compositor starts drawing sooner, but can't actually get it's frame up sooner, which hurts latency for the entire run.

@haraken: Does your patch somehow affect the signal tests use to start scrolling?

Instead of reverting haraken's patch, we should add a small delay before we start the scroll gesture to make the test more realistic.

Yeah, I'd say that my patch is not related to the regression.

My patch may affect the performance of a V8 world initialization, but the regression is happening on mean_input_event_latency.

Adding Ned to comment on the last sentence of comment #11.

Could we try reverting the patch locally to see what effect it has?

To #11: Could we make the wait be s.t like "WaitForGPUServiceToFinish()"? If not, adding some amount of delay that you think is sufficient for all platforms is also ok.

Sorry, for future reference, getting a graph is something like:
catapult$ ./experimental/plot_bisect_results.py https://uberchromegw.corp.google.com/i/tryserver.chromium.perf/builders/android_nexus5X_perf_bisect/builds/1056

But it looks like the jobs are old enough that there are no logs to pull the data from.

Looks like either we wont fix this, or we'd add a small delay before the start of a scroll gesture as in #11. Either way, haraken isn't the right owner. brianderson: do you know who a good owner would be, or the priority of fixing?

WontFix-ing after no update on who could own this, please reopen and assign to an owner if anyone thinks this should be fixed.