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

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


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

chromium-rel-mac12
win-high-dpi

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/15601101f80000

📍 Found significant differences after each of 4 commits.
https://pinpoint-dot-chromeperf.appspot.com/job/15601101f80000

Change password card should be removed if user clears browsing history
By jialiul@chromium.org · Sat Nov 11 01:46:52 2017
chromium @ 8896e7f76b65fc0d7e766ac61068769417f8a6f5

DevTools: Don't reveal UISourceCode on simple rename
By einbinder@chromium.org · Sat Nov 11 02:00:02 2017
chromium @ a8a423fa01eb5fce1b106b1f51dc76cd8586c4f6

Reland "Run angle_perftests on Nexus 5X Perf bot"
By ynovikov@chromium.org · Sat Nov 11 02:00:40 2017
chromium @ 8a6e635083f3a42166078ea53d611332d9b693cd

Move the mojo JS bindings resource into a separate grd file in mojo/pubilc/js.
By yzshen@chromium.org · Sat Nov 11 02:01:09 2017
chromium @ 2efe42776d86948a7e0cdb69ef2462c66bbd8abf

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

yzshen's patch seems more likely than the others.

Hi,

It seems very unlikely that my patch could cause a regression.
That CL moves a resource into its own .grd file. But it is packed into the same resources.pak file eventually. So it is like we move a cc file into a different source set which is eventually compiled into the same binary.

Besides, this resource file is only used by a few WebUI pages, it is definitely not used by any web pages.

The comment on #3 says there is significant difference after *each* of 4 commits. At least some of the others seem as unlikely as my patch. So I would say the tool doesn't really able to identify the culprit.

tdresser@: Please let me know if you have reasons indicating that my patch is likely the culprit. I will be happy to work on it. Thanks!

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

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/12e51ec9f80000

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

I started a few bisect jobs. Let's see whether they are able to identify the issue.

📍 Couldn't reproduce a difference.
https://pinpoint-dot-chromeperf.appspot.com/job/12e51ec9f80000

Thanks yzshen@ - I think you're right that it wasn't your change.
Let's wait for additional bisect results.

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

VR: Disable GL depth testing for browser and overlay
By cjgrant@chromium.org · Sat Nov 11 05:28:33 2017
chromium @ 9f1225c70924c5b3312d0571017f855ddaa60a78

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

=== BISECT JOB RESULTS ===
NO Perf regression found

Bisect Details
  Configuration: winx64_high_dpi_perf_bisect
  Benchmark    : smoothness.tough_animation_cases
  Metric       : frame_times/css_value_type_filter.html?api_css_animations_N_0316

Revision             Result                  N
chromium@515681      60.8552 +- 4.65712      21      good
chromium@515814      60.8019 +- 5.65394      21      bad

To Run This Test
  src/tools/perf/run_benchmark -v --browser=release_x64 --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=css.value.type.filter.html.api.css.animations.N.0316 smoothness.tough_animation_cases

More information on addressing performance regressions:
  http://g.co/ChromePerformanceRegressions

Debug information about this bisect:
  https://chromeperf.appspot.com/buildbucket_job_status/8963014431328920512


For feedback, file a bug with component Speed>Bisection

Hi Tim,

Sorry to also disown the regression.  It's being detected here on Windows and Mac.  The code changed in the VR-related CL runs only on Android, and only when a VR session is started.

I'm still clicking through the graphs and reports here, but I think I'll have to punt this back to Available.

Actually, looking at the plots, it looks to me like the regression un-regressed yesterday.  All the graphs appear to take a big jump back down to where they were before.

cjgrant: thanks for taking a careful look!

+dtu agreed w/cjgrant@ that pinpoint was incorrect in #12.

Going to mark WontFix as bisect can't reproduce and the numbers came back down.

I looked at the data from the Pinpoint jobs and filed https://github.com/catapult-project/catapult/issues/4040 for the incorrect results.