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

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


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

win-high-dpi

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/1680219a840000

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

Surface synchronization: Allocate new LocalSurfaceId on navigation
By samans@chromium.org · Wed Jan 24 22:18:44 2018
chromium @ f7731345b34fd9f87ce5792f5f952f8e5cdfaac8

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

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

commit b46e0efc8062d290e0657c12f22d0453dfd94188
Author: Fady Samuel <fsamuel@chromium.org>
Date: Tue Jan 30 04:48:41 2018

Surface synchronization: Reduce synchronization deadline for navigation

This CL introduces a DeadlinePolicy that clients can specify on a SurfaceLayer.

DeadlinePolicy currently consists of three options:

1. UseExistingDeadline() which uses whatever the current deadline is on the
   provided SurfaceLayer. As deadlines are one shot, the last deadline will
   reset to 0 after commit. If UseExistingDeadline() is used after the last
   commit, then that translates to 0. Otherwise, it translates to use whatever
   the last specified deadline was.

2. UseDefaultDeadline() which uses whatever the system default is for the
   surface synchronization deadline (usually 4 frames).

3. UseSpecifiedDeadline(uint32_t) which allows the client to specify a deadline
   in terms of number of frames.

Navigation now gets a "UseExistingDeadline" policy which will usually translate
into a deadline of 0 unless a resize happened just before it.

Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I83a3106fa602fac1eab52b1493affa46131f9383
Bug:  672962 , 806835 
Reviewed-on: https://chromium-review.googlesource.com/890242
Commit-Queue: Fady Samuel <fsamuel@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Saman Sami <samans@chromium.org>
Cr-Commit-Position: refs/heads/master@{#532757}
[modify] https://crrev.com/b46e0efc8062d290e0657c12f22d0453dfd94188/cc/BUILD.gn
[add] https://crrev.com/b46e0efc8062d290e0657c12f22d0453dfd94188/cc/layers/deadline_policy.cc
[add] https://crrev.com/b46e0efc8062d290e0657c12f22d0453dfd94188/cc/layers/deadline_policy.h
[modify] https://crrev.com/b46e0efc8062d290e0657c12f22d0453dfd94188/cc/layers/surface_layer.cc
[modify] https://crrev.com/b46e0efc8062d290e0657c12f22d0453dfd94188/cc/layers/surface_layer.h
[modify] https://crrev.com/b46e0efc8062d290e0657c12f22d0453dfd94188/cc/layers/surface_layer_unittest.cc
[modify] https://crrev.com/b46e0efc8062d290e0657c12f22d0453dfd94188/chrome/browser/ui/overlay/overlay_surface_embedder.cc
[modify] https://crrev.com/b46e0efc8062d290e0657c12f22d0453dfd94188/content/browser/renderer_host/browser_compositor_view_mac.mm
[modify] https://crrev.com/b46e0efc8062d290e0657c12f22d0453dfd94188/content/browser/renderer_host/delegated_frame_host.cc
[modify] https://crrev.com/b46e0efc8062d290e0657c12f22d0453dfd94188/content/browser/renderer_host/delegated_frame_host.h
[modify] https://crrev.com/b46e0efc8062d290e0657c12f22d0453dfd94188/content/browser/renderer_host/render_widget_host_view_aura.cc
[modify] https://crrev.com/b46e0efc8062d290e0657c12f22d0453dfd94188/content/browser/renderer_host/render_widget_host_view_aura.h
[modify] https://crrev.com/b46e0efc8062d290e0657c12f22d0453dfd94188/content/renderer/child_frame_compositing_helper.cc
[modify] https://crrev.com/b46e0efc8062d290e0657c12f22d0453dfd94188/third_party/WebKit/Source/platform/graphics/SurfaceLayerBridge.cpp
[modify] https://crrev.com/b46e0efc8062d290e0657c12f22d0453dfd94188/ui/android/delegated_frame_host_android.cc
[modify] https://crrev.com/b46e0efc8062d290e0657c12f22d0453dfd94188/ui/aura/local/window_port_local.cc
[modify] https://crrev.com/b46e0efc8062d290e0657c12f22d0453dfd94188/ui/aura/mus/client_surface_embedder.cc
[modify] https://crrev.com/b46e0efc8062d290e0657c12f22d0453dfd94188/ui/aura/mus/window_port_mus.cc
[modify] https://crrev.com/b46e0efc8062d290e0657c12f22d0453dfd94188/ui/compositor/layer.cc
[modify] https://crrev.com/b46e0efc8062d290e0657c12f22d0453dfd94188/ui/compositor/layer.h
[modify] https://crrev.com/b46e0efc8062d290e0657c12f22d0453dfd94188/ui/compositor/layer_unittest.cc

Under rare circumstances, we expect that the renderer may submit the first CompositorFrame after page load one BeginFrame later than before because it is waiting for a response from the browser. This should happen very infrequently (very few pages regressed) and when it happens it should not be user-perceivable, and also I'll repeat that it's only during page load. We do have certain mitigations in mind that we will implement soon.

This appears to be fixed now. Closing.