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

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


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

chromium-rel-win7-gpu-ati

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/16a49fc1840000

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

canvas: Keep images locked during raster. by khushalsagar@chromium.org
chromium @ aa36bffbca291c237487d2374d416a9c59f4de2e

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

https://chromium-review.googlesource.com/c/chromium/src/+/919966 should address this.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cde9d1d1e464957716e4e15f44810fe28753e4df

commit cde9d1d1e464957716e4e15f44810fe28753e4df
Author: Khushal <khushalsagar@chromium.org>
Date: Fri Feb 16 22:18:07 2018

canvas: Avoid unnecessary book-keeping of images in CanvasImageProvider.

If an image can be used for raster directly, it doesn't need to hit
the decode cache or be unlocked. Avoid unnecessary tracking for them
in CanvasImageProvider.

R=ericrk@chromium.org, junov@chromium.org

Bug:  809130 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: Ib899f79c8a208f3bcb2395595162561e12757987
Reviewed-on: https://chromium-review.googlesource.com/919966
Reviewed-by: Justin Novosad <junov@chromium.org>
Reviewed-by: Eric Karl <ericrk@chromium.org>
Commit-Queue: Khushal <khushalsagar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#537430}
[modify] https://crrev.com/cde9d1d1e464957716e4e15f44810fe28753e4df/cc/paint/image_provider.h
[modify] https://crrev.com/cde9d1d1e464957716e4e15f44810fe28753e4df/cc/tiles/gpu_image_decode_cache.cc
[modify] https://crrev.com/cde9d1d1e464957716e4e15f44810fe28753e4df/cc/tiles/software_image_decode_cache_utils.cc
[modify] https://crrev.com/cde9d1d1e464957716e4e15f44810fe28753e4df/third_party/WebKit/Source/platform/graphics/CanvasResourceProvider.cpp

The change in #5 fixed most of the regressions. The only ones remaining are draw-hw-accelerated-canvas-2d-to-sw-canvas-2d and getImageData on mac/android.

📍 Pinpoint job started.
https://chromeperf.appspot.com/job/148242df840000

getImageData is also back up, on the bots that caught up with the change above. draw-hw-accelerated-canvas-2d-to-sw-canvas-2d is not fixed, and looks like it improved in a previous change which was then partially reverted (https://chromium.googlesource.com/chromium/src/+/d507be380ff2dbbea2c5c2581d07c3d803221d41). I'm not sure if its related, started a bisect for it.

📍 Pinpoint job started.
https://chromeperf.appspot.com/job/1196e50f840000

📍 Found a significant difference after 1 commit.
https://chromeperf.appspot.com/job/1196e50f840000

No eager creation of CanvasResourceProvider when canvas 2d bridge is created by xlai@chromium.org
https://chromium.googlesource.com/chromium/src/+/d507be380ff2dbbea2c5c2581d07c3d803221d41

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

📍 Found a significant difference after 1 commit.
https://chromeperf.appspot.com/job/148242df840000

No eager creation of CanvasResourceProvider when canvas 2d bridge is created by xlai@chromium.org
https://chromium.googlesource.com/chromium/src/+/d507be380ff2dbbea2c5c2581d07c3d803221d41

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

I did some local experiments on my machine, combined with the perf graph trace in android-nexus5, and think that this regression does not indicate functional issue. 

This CL https://chromium-review.googlesource.com/c/chromium/src/+/864630 improves the perf gragh, because the switch of CanvasResourceProvider creation time point, causes the the test to accelerate up the non-accelerated canvas and do a draw image on two accelerated canvases. See https://bugs.chromium.org/p/chromium/issues/detail?id=806066 for more detailed explanation.

The CL https://chromium-review.googlesource.com/c/chromium/src/+/896084 regresses the perf graph, because it partially reverts the previous CL so that its CanvasResourceProvider is created as same as before, causing the test to decelerate down the accelerated canvas and do a draw image on two un-accelerated canvases.

One up. One down. So no harm in overall.