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

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


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

chromium-rel-win7-gpu-intel

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

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

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

The regression here is simply from the GetDecodedImageForDraw and DrawWithImageFinished calls to the sw cache. The particular test case is a stress test and uses 2000 images every frame. The mean main frame time went up from 22.2 to 23 ms. The time to decode, which is done in the first frame, only changed from 196 to 200ms.

Each call to hit the sw cache is a minor additional overhead which starts to show significant impact in this case, but there isn't much we can do to avoid it.