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

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


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

win-high-dpi

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/15a80eed440000

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

Add Windows 10 Custom Titlebar feature flag and enable it by default. by bsep@chromium.org
https://chromium.googlesource.com/chromium/src/+/979c3c4d8355e456339c648db65c8201991b43af

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

CC brianderson@ as the test owner. I don't know how to investigate the "queueing_durations" metric, which is what regressed, so I need help.

The patch in question is enabling a feature that moves some of the top chrome renderering into Views code, instead of letting Windows handle it. It does not affect page renderering directly. It might slightly increase global renderering load, but I don't have enough context to understand the magnitude of the impact.

I tried running this test locally (not on a high dpi monitor, though). As bsep@ says, the blamed CL affects the drawing of the chrome titlebar. The test only draws the title bar a few times (4 or 5) so it shouldn't be able to affect overall performance in such a significant way. There is a slight change to the view structure, a few extra views in the title bar, but they're not getting redrawn, so they shouldn't be affecting the test. Running the test locally with and without the CL doesn't show any correlation between the CL and perf regressions.

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/115f651ec40000

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

Add Windows 10 Custom Titlebar feature flag and enable it by default. by bsep@chromium.org
https://chromium.googlesource.com/chromium/src/+/979c3c4d8355e456339c648db65c8201991b43af

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

Assigning to test owner skyostil: can you help davidbienvenu understand how the queuing_durations metric and how to dig into this regression, as well as clarifying how severe the regression is? See #4 and #6

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

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

Revert "Add Windows 10 Custom Titlebar feature flag and enable it by default." by davidbienvenu@chromium.org
https://chromium-review.googlesource.com/c/chromium/src/+/1022978/1

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

The queueing duration metric keeps track of how long the BeginMainFrame task gets queued for on the renderer main thread. I took a look at the before and after traces and didn't see any significant problems. The only real change is that the BeginMainFrame event's execution time rises from 2.3ms to 2.5ms. Since the patch only touches the browser process as far as I can tell, I'm not sure how it could have had this effect in the renderer. In any case, the absolute regression is small enough to not worry about.

Based on comment #6 and #13, I'm satisfied there's nothing to do, so I'm closing this.