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

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


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

android-nexus5
android-nexus5X
chromium-rel-win10

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/1697413d440000

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

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

Split the android regressions into  bug 825796  since the culprit CL here looks to be Windows-only.

CC vmiura@ as the test owner. I don't know how to investigate the "tasks_per_frame_total_all" 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 ran this perf test locally and the accused CL doesn't seem to be involved. I added instrumentation for the OnPaint method for the titlebar and it's called the same number of times with and without this CL (4 or 5, so a minimal number). Also, running the test locally with and without the CL, there doesn't seem to be a correlation between increased numbers and running with the CL.

Finally, this history makes it look like the delta is well within the noise, and the regression whereby this number was at 0 may have confused things.
https://chromeperf.appspot.com/group_report?bug_id=825596

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/148e67fec40000

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

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 vmiura to help clarify:
1) What the metric is measuring and how it can be debugged
2) Whether this regression is significant enough to dig into more deeply.

Looking at the graph: https://chromeperf.appspot.com/group_report?bug_id=825596
We do see a clear regression from just under 2000 tasks per second to 2100 which is clearly reproduced at the CL in question in both bisects (#3 and #9). But it looks like more information on the metric and severity would be needed for the CL author to address this.

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

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

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

I did a try job with the original CL reverted and the averages for tasks_per_frame_total_all were very close (1732 vs 1731). The main difference was the max (2060 w/ the original change, 1950 w/o it).

Closing, obsolete.  thread_times benchmarks and metrics have migrated to rendering.mobile and TBMv2 versions.