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

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


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

chromium-rel-mac11-air
chromium-rel-mac11-pro
chromium-rel-mac12

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/159248dbc40000

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

cc: Enable checkerimaging only on developer opt-in. by khushalsagar@chromium.org
https://chromium.googlesource.com/chromium/src/+/465219a86327b393fb6d92e894fd80919f9f9a0a

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

Interesting, the regression is in tile memory with the renderer reporting a lot more. This change affects raster and decode scheduling so some impact on how much raster work we schedule (re-rasterization of tiles to replace images affecting the amount of pre-paint that can be done?) is possible. I'm going to try to capture a dump with a longer wait, to verify if it still repros after things have stabilized.

 Issue 840772  has been merged into this issue.

I tried debugging this today, looking at memory traces with async decoding and without, and there is definitely more tile resource use without async decoding. Its not anything with pre-paint scheduling, I disabled that in the local run. And the test also does any raster work only during the initial load, after that there is no interaction for ~25 seconds.

Also there is clearly more raster work with async decodes as expected, 22 vs 14 raster tasks. But I'm still confused about why that is resulting in less resources, 5 vs 8, in the renderer.

Are these additional resources in the resource pool? Like we have a slightly higher watermark and then keep more around?