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

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


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

android-webview-nexus5X
android-webview-nexus6
chromium-rel-mac11-pro
chromium-rel-mac12
chromium-rel-win7-gpu-intel
win-high-dpi

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/11ebb485440000

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

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

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

[scheduler] Issue RequestBeginMainFrameNotExpected call asynchronously. by altimin@chromium.org
https://chromium.googlesource.com/chromium/src/+/1bfa23fdee284c09f24c0ea1ec805939a96daa27

[heap-profiler] Annotate global handles by mlippautz@chromium.org
https://chromium.googlesource.com/chromium/src/+/1ab087d88398ada0c6daf615e8306e5b29d684c2

<b>[CI] Stop tracking <*Gradient> 'href' references through SVGResources</b> by fs@opera.com
https://chromium.googlesource.com/chromium/src/+/ce851e47bd77773970a805acd62ec1627b0aaa76

Check negative getImageData params for Integer overflow by zakerinasab@chromium.org
https://chromium.googlesource.com/chromium/src/+/07f4ef13b27fb071a101055d8a2f52581fc7bfbb

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

Looks like there may be a risk of conflation here: the pinpoint above might go well together with  issue 823473 , while blink_perf.image_decoder appear to be recovering (might need a few more samples there to say for sure.)

http://crrev.com/c/964927 just adds a simple integer overflow check to getImageData params. Should not affect image decoder perf.

I reassociated some of the graphs to other bugs ( issue 823473  mostly.) If someone could start a new bisect on one of the remaining graphs that'd be great (I get a 500 error ATM.) Kicking over to a component that reflects the tests.

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/1283870b440000

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

Roll src/third_party/catapult/ 7b53f088f..f73167a68 (1 commit) by catapult-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com
https://chromium.googlesource.com/chromium/src/+/320ac37b57c63feeac20bd169d80efdaa4c0a298

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

mythria: the only CL in the catapult roll blamed above is "2018-03-13 mythria Ignore i-frame navigationStart events when computing LoadExpectation" -- could this be a measurement change?

Yes, that could have caused a measurement change. Before my cl, we used to include some of the i-frame navigationStart events as main frame navigationStart events. My cl ignores these events corresponding to the i-frames, so it is quite possible that the timeToMeaningfulPaint has changed due to this.  We used to ignore these events prior to this cl: https://chromium-review.googlesource.com/c/catapult/+/897491. 

I am marking this as won't fix. Since this is a change in the measurement. Feel free to reopen if you think otherwise.