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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDghv3PtwoM


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

chromium-rel-win7-gpu-nvidia

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8978177796190241488

=== BISECT JOB RESULTS ===
Perf regression found but unable to narrow commit range

Build failures prevented the bisect from narrowing the range further.


Bisect Details
  Configuration: winx64nvidia_perf_bisect
  Benchmark    : performance_browser_tests
  Metric       : CastV2Performance_gpu_60fps/total_latency
  Change       : 16.78% | 27.8494598571 -> 32.5237409286

Suspected Commit Range
  17 commits in range
  https://chromium.googlesource.com/chromium/src/+log/d10a8c41ef88566b25aff3f763ac7ec605bac4ea..94274172ed5f2f5f5b2ead35f07e5e011a73e3b4


Revision             Result                  N
chromium@474184      27.8495 +- 5.38597      14       good
chromium@474185      28.6005 +- 7.16248      14       good
chromium@474186      ---                     ---      build failure
---                  ---                     ---      too many build failures to list
chromium@474201      ---                     ---      build failure
chromium@474202      32.8788 +- 13.6918      14       bad
chromium@474206      33.1247 +- 10.8854      9        bad
chromium@474228      33.631 +- 9.33819       6        bad
chromium@474272      32.5237 +- 14.0038      14       bad

To Run This Test
  .\src\out\Release_x64\performance_browser_tests.exe --test-launcher-print-test-stdio=always --enable-gpu

Debug Info
  https://chromeperf.appspot.com/buildbucket_job_status/8978177796190241488

Is this bisect wrong?
  https://chromeperf.appspot.com/bad_bisect?try_job_id=6616483301425152


| O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq
|  X  | for more information addressing perf regression bugs. For feedback,
| / \ | file a bug with component Speed>Bisection.  Thank you!

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8978088034461128432

with a narrow range

 Issue 727629  has been merged into this issue.

=== BISECT JOB RESULTS ===
Perf regression found but unable to narrow commit range

Build failures prevented the bisect from narrowing the range further.


Bisect Details
  Configuration: winx64nvidia_perf_bisect
  Benchmark    : performance_browser_tests
  Metric       : CastV2Performance_gpu_60fps/total_latency
  Change       : 25.25% | 27.4392385 -> 34.3672933333

Suspected Commit Range
  17 commits in range
  https://chromium.googlesource.com/chromium/src/+log/d10a8c41ef88566b25aff3f763ac7ec605bac4ea..94274172ed5f2f5f5b2ead35f07e5e011a73e3b4


Revision             Result                  N
chromium@474185      27.4392 +- 1.68314      6        good
chromium@474186      ---                     ---      build failure
---                  ---                     ---      too many build failures to list
chromium@474201      ---                     ---      build failure
chromium@474202      34.3673 +- 6.21345      6        bad

To Run This Test
  .\src\out\Release_x64\performance_browser_tests.exe --test-launcher-print-test-stdio=always --enable-gpu

Debug Info
  https://chromeperf.appspot.com/buildbucket_job_status/8978088034461128432

Is this bisect wrong?
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5239439611133952


| O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq
|  X  | for more information addressing perf regression bugs. For feedback,
| / \ | file a bug with component Speed>Bisection.  Thank you!

miu: This change is in the offending range:

https://chromium.googlesource.com/chromium/src/+/50ca2ed80efff90dcc3192c1e3e1c2d782d14a91

Is is related?

miu: any ideas on #9?

Yes, my change actually changed the performance test itself. :) The goal was to reduce volatility in the measurements, among many other fixes.

I believe the latency measurement increase is due to the fixes involving how the test associated "begin" with "end" tracing events. The old code had some hacks to deal with "missing data points" that were no longer necessary. Those hacks would have biased the measurement down (as we see in the graphs).

So, marking WontFix.