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

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


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

android-one
android-webview-nexus6
chromium-rel-mac12
chromium-rel-mac12-mini-8gb
chromium-rel-win7-gpu-nvidia
win-high-dpi

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

📍 Found significant differences after each of 5 commits.
https://pinpoint-dot-chromeperf.appspot.com/job/16cb6ee8840000

Allow stack-mode for OOP HP to be Finch configurable.
By erikchen@chromium.org · Fri Jan 19 19:39:31 2018
chromium @ e113c3b18bffabfd875e3a24a6d6862c0f61e19f

[bindings] Add missing write barrier in DOMDataStore.
By ulan@chromium.org · Fri Jan 19 19:44:25 2018
chromium @ 8cfb6c74d5ece32d20f601781a8e8eae002ecd43

blink/canvas: Switch Canvas to use cc's ImageDecodeCache.
By khushalsagar@chromium.org · Fri Jan 19 19:47:47 2018
chromium @ 60916ba1169d9207e048e2eca290c946ba37fcad

[CrOS Tether] Increase timeout for receiving ConnectTetheringResponse.
By khorimoto@google.com · Fri Jan 19 20:42:44 2018
chromium @ b4adc605cf848a97561924ada89cab404ecbdab0

Re-enable a GPU unittest and update it for the new browser creation API.
By kbr@chromium.org · Fri Jan 19 21:06:40 2018
chromium @ 2922c9017fcd63c0a738fff449731b05f9f66419

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

It's definitely not my patch.

khushalsagar@: possibly yours?

Yup, most likely my change. The main frames have gone up by ~100 ms. Looking into it.

 Issue 804299  has been merged into this issue.

The test case that regressed uses an image in 2000 ops every frame, and the gpu discardable is locked/unlocked after op and the cost adds up. The solution would be to have canvas lock images up till a limit during raster and flush at regular intervals. I'm looking into it.

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

commit f3dfefb33eecf69189a65307cbe8be5ca153f6cf
Author: Khushal <khushalsagar@chromium.org>
Date: Wed Jan 24 23:11:27 2018

cc: Allow budgeting for images decoded during draw.

For images not pre-decoded using a task, they are always assumed to be
at-raster and don't count against the cache budget for locking beyond
the duration of the op that uses them. Allowing them to be budgeted
would help canvas use-cases which repeatedly use the same image by
avoiding the lock/unlock churn for every op, since canvas never
performs any pre-decoding.

R=ericrk@chromium.org

Bug:  804325 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel
Change-Id: Ia316121af3fcfbe1e87c5750bf92357888c678bb
Reviewed-on: https://chromium-review.googlesource.com/882553
Reviewed-by: Eric Karl <ericrk@chromium.org>
Commit-Queue: Khushal <khushalsagar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#531738}
[modify] https://crrev.com/f3dfefb33eecf69189a65307cbe8be5ca153f6cf/cc/paint/decoded_draw_image.cc
[modify] https://crrev.com/f3dfefb33eecf69189a65307cbe8be5ca153f6cf/cc/paint/decoded_draw_image.h
[modify] https://crrev.com/f3dfefb33eecf69189a65307cbe8be5ca153f6cf/cc/paint/oop_pixeltest.cc
[modify] https://crrev.com/f3dfefb33eecf69189a65307cbe8be5ca153f6cf/cc/paint/paint_op_buffer_unittest.cc
[modify] https://crrev.com/f3dfefb33eecf69189a65307cbe8be5ca153f6cf/cc/paint/paint_shader_unittest.cc
[modify] https://crrev.com/f3dfefb33eecf69189a65307cbe8be5ca153f6cf/cc/paint/scoped_raster_flags_unittest.cc
[modify] https://crrev.com/f3dfefb33eecf69189a65307cbe8be5ca153f6cf/cc/raster/playback_image_provider.cc
[modify] https://crrev.com/f3dfefb33eecf69189a65307cbe8be5ca153f6cf/cc/raster/playback_image_provider_unittest.cc
[modify] https://crrev.com/f3dfefb33eecf69189a65307cbe8be5ca153f6cf/cc/test/stub_decode_cache.cc
[modify] https://crrev.com/f3dfefb33eecf69189a65307cbe8be5ca153f6cf/cc/tiles/gpu_image_decode_cache.cc
[modify] https://crrev.com/f3dfefb33eecf69189a65307cbe8be5ca153f6cf/cc/tiles/gpu_image_decode_cache.h
[modify] https://crrev.com/f3dfefb33eecf69189a65307cbe8be5ca153f6cf/cc/tiles/gpu_image_decode_cache_unittest.cc
[modify] https://crrev.com/f3dfefb33eecf69189a65307cbe8be5ca153f6cf/cc/tiles/software_image_decode_cache.cc

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

commit aa36bffbca291c237487d2374d416a9c59f4de2e
Author: Khushal <khushalsagar@chromium.org>
Date: Fri Feb 02 01:21:34 2018

canvas: Keep images locked during raster.

Canvas currently uses cc's ImageDecodeCache in at-raster mode, i.e, all
images are locked only for the duration of a draw op. For cases where
a small set of images are used repeatedly across ops, this causes a
lot of lock/unlock churn on GPU discardable which can be expensive.

This change ensures that we unlock images only at the end of a canvas
frame. This includes the deferred raster mode where the canvas
maintains a PaintRecord that is flushed during the main frame and at
the end of a script task that mutates the canvas. In addition, the
cache maintains a memory budget to ensure that we purge regularly if
the budget is exceeded.

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

Bug:  804325 
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: Ic5a1f65993ca9af874a0351215fb9aa6ca41140f
Reviewed-on: https://chromium-review.googlesource.com/884881
Reviewed-by: Mohammad Reza Zakerinasab <zakerinasab@chromium.org>
Reviewed-by: Justin Novosad <junov@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Reviewed-by: Eric Karl <ericrk@chromium.org>
Commit-Queue: Khushal <khushalsagar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#533894}
[modify] https://crrev.com/aa36bffbca291c237487d2374d416a9c59f4de2e/cc/paint/decode_stashing_image_provider.h
[modify] https://crrev.com/aa36bffbca291c237487d2374d416a9c59f4de2e/cc/paint/image_provider.cc
[modify] https://crrev.com/aa36bffbca291c237487d2374d416a9c59f4de2e/cc/paint/image_provider.h
[modify] https://crrev.com/aa36bffbca291c237487d2374d416a9c59f4de2e/cc/paint/paint_op_buffer.cc
[modify] https://crrev.com/aa36bffbca291c237487d2374d416a9c59f4de2e/cc/paint/scoped_raster_flags_unittest.cc
[modify] https://crrev.com/aa36bffbca291c237487d2374d416a9c59f4de2e/cc/paint/skia_paint_canvas.cc
[modify] https://crrev.com/aa36bffbca291c237487d2374d416a9c59f4de2e/cc/paint/skia_paint_canvas.h
[modify] https://crrev.com/aa36bffbca291c237487d2374d416a9c59f4de2e/cc/raster/playback_image_provider.cc
[modify] https://crrev.com/aa36bffbca291c237487d2374d416a9c59f4de2e/content/renderer/webgraphicscontext3d_provider_impl.cc
[modify] https://crrev.com/aa36bffbca291c237487d2374d416a9c59f4de2e/third_party/WebKit/Source/core/html/canvas/HTMLCanvasElement.cpp
[modify] https://crrev.com/aa36bffbca291c237487d2374d416a9c59f4de2e/third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridge.cpp
[modify] https://crrev.com/aa36bffbca291c237487d2374d416a9c59f4de2e/third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridgeTest.cpp
[modify] https://crrev.com/aa36bffbca291c237487d2374d416a9c59f4de2e/third_party/WebKit/Source/platform/graphics/CanvasResourceProvider.cpp
[modify] https://crrev.com/aa36bffbca291c237487d2374d416a9c59f4de2e/third_party/WebKit/Source/platform/graphics/CanvasResourceProvider.h
[modify] https://crrev.com/aa36bffbca291c237487d2374d416a9c59f4de2e/third_party/WebKit/Source/platform/graphics/test/FakeWebGraphicsContext3DProvider.h

And the graphs have recovered. \o/