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

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


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

win-high-dpi

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14c7c62e840000

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/14c7c62e840000

Surface synchronization: Reset deadline to 0 after one-shot. by fsamuel@chromium.org
chromium @ 4717fddfddb2640549abf1a6d689ac6f9c2bca96

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

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

commit 875ccf44315f9e9db712c648e684d05361444639
Author: Fady Samuel <fsamuel@chromium.org>
Date: Tue Feb 13 18:30:22 2018

Surface synchronization: Use 0 deadline on new SurfaceLayers

On cross-process navigations, we allocate a new RenderWidgetHostView
and DelegatedFrameHost, creating a new SurfaceLayer. The policy for
navigation is DeadlinePolicy::UseExistingDeadline. Prior to this CL,
this resolved to the system default deadline. This meant that every
cross-process navigation blocked for ~4 BeginFrames. This CL ensures
that the deadline is 0.

Bug:  808616 ,  672962 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel
Change-Id: I62f9f00b49d16787d8ff6dd1ed218bb03dc452d9
Reviewed-on: https://chromium-review.googlesource.com/916545
Commit-Queue: Fady Samuel <fsamuel@chromium.org>
Reviewed-by: Saman Sami <samans@chromium.org>
Cr-Commit-Position: refs/heads/master@{#536406}
[modify] https://crrev.com/875ccf44315f9e9db712c648e684d05361444639/cc/layers/surface_layer.h
[modify] https://crrev.com/875ccf44315f9e9db712c648e684d05361444639/cc/layers/surface_layer_unittest.cc