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

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


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

chromium-rel-mac12

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/107157c3c40000

📍 Found significant differences after each of 2 commits.
https://pinpoint-dot-chromeperf.appspot.com/job/107157c3c40000

Qualify #includes in files generated by make_qualified_names.py. by tkent@chromium.org
https://chromium.googlesource.com/chromium/src/+/66e7407fa8b5729ad380bd4c3e52cfc43b9a5db4

blink: Set up a cc::SoftwareImageDecodeCache for canvas image decodes. by khushalsagar@chromium.org
https://chromium.googlesource.com/chromium/src/+/49fc8a9c4a9eb46faa2258daea5bdbee48da7dcb

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

Interestingly the regression is only for drawimage-not-pixelaligned. I don't think this is related to any of the filtering quality changes in this patch. I did a local run with always using medium with both cc and skia cache and I can still repro a regression, avg runs/s going from 5926 to 5337. Need to investigate this more.

It was a false alarm that the regression is drawimage-not-pixelaligned only. There is also a drop in drawimage.html (https://chromeperf.appspot.com/report?sid=8e2e7fb87bed39a25727b98ab61ebdbcae07fb4f961622e1dca1f65c639b9c7e) in the same range. There is definitely no scaling, we use the image at the original size.
Again, I think its the extra cost of querying the cache for the image showing up. Its not good that retrieving a cached decode from the cache has this significant cost. I'm going to try to do some profiling to improve this.

 Issue 841225  has been merged into this issue.

 Issue 841414  has been merged into this issue.