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

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


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

android-nexus5x-perf

rendering.mobile - Benchmark documentation link:
  https://bit.ly/rendering-benchmarks

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/16d63f34e40000

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

Elements with fixed bottom and top stick to top by bokan@chromium.org
https://chromium.googlesource.com/chromium/src/+/77b67445ba6e415e8b41b5b6fd5c016c7195206d
0.0065 → 0.3756 (+0.3691)

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

Benchmark documentation link:
  https://bit.ly/rendering-benchmarks

Seems surprising this CL would cause a regression. Will investigate.

I'll kick off another bisect, to make sure.

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/16f3c5fce40000

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

Elements with fixed bottom and top stick to top by bokan@chromium.org
https://chromium.googlesource.com/chromium/src/+/77b67445ba6e415e8b41b5b6fd5c016c7195206d
thread_total_all_cpu_time_per_frame: 30.77 → 32.72 (+1.944)

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

Benchmark documentation link:
  https://bit.ly/rendering-benchmarks

Looks real - will investigate.

I can't reproduce it locally, but I'm pretty sure I know where the regression is coming from. Will confirm on a Nexus 5X on Monday.

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

commit b2d410710e7ea7c5a33798ff6b5d5191b1951b5e
Author: David Bokan <bokan@chromium.org>
Date: Fri Oct 26 17:25:23 2018

Performance fix for top controls-affected raster

In https://crrev.com/77b67445ba6e415e8b41b5b6fd5c016c7195206d I changed
PictureLayerImpl::UpdateViewportRectForTilePriorityInContentSpace by the
"live" bounds-delta, which is the exact amount that the browser controls
have been hidden by. Prevoiusly, this method would expand by the entire
top controls height.

That CL caused the linked performance regression. I suspect this happens
because we would progressively raster slightly more of the layer, rather
than rastering the entire browser-controls based bar in one shot. This
CL goes back to expanding the visible rect by the entire
browser-controls height rather than using the amount-hidden.

Bug:  890870 
Change-Id: Id3a2b019e394005fe4434b7b6bf4a37f81f4550c
Reviewed-on: https://chromium-review.googlesource.com/c/1297281
Reviewed-by: vmpstr <vmpstr@chromium.org>
Commit-Queue: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#603130}
[modify] https://crrev.com/b2d410710e7ea7c5a33798ff6b5d5191b1951b5e/cc/layers/picture_layer_impl.cc

The metrics have recovered. Requesting merge since this regressed in M71

This bug requires manual review: M71 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Pls apply appropriate OSs label.

Merge approved to 71, branch 3578.

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

commit 40c20492a7b90330951ff277bc3dc0d483ac157c
Author: David Bokan <bokan@chromium.org>
Date: Tue Oct 30 15:46:03 2018

Performance fix for top controls-affected raster

In https://crrev.com/77b67445ba6e415e8b41b5b6fd5c016c7195206d I changed
PictureLayerImpl::UpdateViewportRectForTilePriorityInContentSpace by the
"live" bounds-delta, which is the exact amount that the browser controls
have been hidden by. Prevoiusly, this method would expand by the entire
top controls height.

That CL caused the linked performance regression. I suspect this happens
because we would progressively raster slightly more of the layer, rather
than rastering the entire browser-controls based bar in one shot. This
CL goes back to expanding the visible rect by the entire
browser-controls height rather than using the amount-hidden.

Bug:  890870 
Change-Id: Id3a2b019e394005fe4434b7b6bf4a37f81f4550c
Reviewed-on: https://chromium-review.googlesource.com/c/1297281
Reviewed-by: vmpstr <vmpstr@chromium.org>
Commit-Queue: David Bokan <bokan@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#603130}(cherry picked from commit b2d410710e7ea7c5a33798ff6b5d5191b1951b5e)
Reviewed-on: https://chromium-review.googlesource.com/c/1307836
Reviewed-by: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#393}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}
[modify] https://crrev.com/40c20492a7b90330951ff277bc3dc0d483ac157c/cc/layers/picture_layer_impl.cc

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

Commit: 40c20492a7b90330951ff277bc3dc0d483ac157c
Author: bokan@chromium.org
Commiter: bokan@chromium.org
Date: 2018-10-30 15:46:03 +0000 UTC

Performance fix for top controls-affected raster

In https://crrev.com/77b67445ba6e415e8b41b5b6fd5c016c7195206d I changed
PictureLayerImpl::UpdateViewportRectForTilePriorityInContentSpace by the
"live" bounds-delta, which is the exact amount that the browser controls
have been hidden by. Prevoiusly, this method would expand by the entire
top controls height.

That CL caused the linked performance regression. I suspect this happens
because we would progressively raster slightly more of the layer, rather
than rastering the entire browser-controls based bar in one shot. This
CL goes back to expanding the visible rect by the entire
browser-controls height rather than using the amount-hidden.

Bug:  890870 
Change-Id: Id3a2b019e394005fe4434b7b6bf4a37f81f4550c
Reviewed-on: https://chromium-review.googlesource.com/c/1297281
Reviewed-by: vmpstr <vmpstr@chromium.org>
Commit-Queue: David Bokan <bokan@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#603130}(cherry picked from commit b2d410710e7ea7c5a33798ff6b5d5191b1951b5e)
Reviewed-on: https://chromium-review.googlesource.com/c/1307836
Reviewed-by: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#393}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}