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

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=9e8b268f85354b72bbd58118301b762a5dc91cc8533f2561a12ad2039f5abc20


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

chromium-rel-win10
chromium-rel-win8-dual

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

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

Hi dtapuska@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 : Dave Tapuska
  Commit : fbf2168e533bf593c0dfc5300f6a86f13fda3845
  Date   : Fri Sep 08 03:15:11 2017
  Subject: Reland "Enable mojo input messages on all platforms other than android."

Bisect Details
  Configuration: winx64_10_perf_bisect
  Benchmark    : smoothness.top_25_smooth
  Metric       : first_gesture_scroll_update_latency/https___www.google.com__hl_en_q_barack+obama
  Change       : 582.87% | 1.67566666667 -> 11.4426666667

Revision             Result                   N
chromium@500453      1.67567 +- 0.161342      6      good
chromium@500484      1.70317 +- 0.243571      6      good
chromium@500492      1.70717 +- 0.239029      6      good
chromium@500494      1.72383 +- 0.211038      6      good
chromium@500495      1.6815 +- 0.166732       6      good
chromium@500496      11.509 +- 11.4938        6      bad       <--
chromium@500500      12.0912 +- 10.7479       6      bad
chromium@500515      11.4427 +- 12.789        6      bad

To Run This Test
  src/tools/perf/run_benchmark -v --browser=release_x64 --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=https...www.google.com..hl.en.q.barack.obama smoothness.top_25_smooth

More information on addressing performance regressions:
  http://g.co/ChromePerformanceRegressions

Debug information about this bisect:
  https://chromeperf.appspot.com/buildbucket_job_status/8968746888026314256


For feedback, file a bug with component Speed>Bisection

 Issue 764341  has been merged into this issue.

 Issue 764724  has been merged into this issue.

The windows regressions are likely because the timestamp clobbering (https://cs.chromium.org/chromium/src/content/renderer/input/input_event_filter.cc?q=input_event_filter.cc&dr&l=246) is not implemented.

However since this is Windows 10 the timestamp should be high resolution but I wonder if the code is actually using a low resolution timer because of virtualization of the bots?

Needless to say I'll try to implement the clobbering and see what happens.

Re #6, the bots do run tests on real hardware, and at least win-high-dpi is a laptop that pushes pixels to the screen. If you do find differences between the lab setup and end users please let us know!

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

commit 9c9e5f2689d74570cf1b7f876d6e201cb883f5a3
Author: Dave Tapuska <dtapuska@chromium.org>
Date: Thu Sep 21 01:06:45 2017

Override the event timestamp if the time is not consistent.

Ensure we clobber the event timestamp if the time is not consistent
across processes. InputEventFilter has similar code and ensure the
mojo event path has the same code.

BUG= 763897 

Change-Id: I5d15ac4490fef96cd42ad496daecde9a8fe000b2
Reviewed-on: https://chromium-review.googlesource.com/675043
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Timothy Dresser <tdresser@chromium.org>
Cr-Commit-Position: refs/heads/master@{#503305}
[modify] https://crrev.com/9c9e5f2689d74570cf1b7f876d6e201cb883f5a3/content/renderer/input/widget_input_handler_manager.cc

The times for these first gesture scroll update latency are expected to be under a frame. They were close to 2ms before because of the timing of the events now that the mojo channel and the begin frame signal are on different channels things aren't necessarily synchronous. This is expected in a real life scenario as well. If you compare these graphs to other platforms (linux, mac) for the same test they appear to be reasonable.

The duplicated bugs also are explained:
764341 - we expect compositor tasks to increase (as we've moved IO tasks to the compositor thread with mojo)
764724 - the total number of frames decreased by about 10% (the avg input latency decreased by 4ms) causing a shift in the metric