Can reproduce this on Chrome Mac 54.0.2840.71. Not reproducible on Linux. 

I can reproduce this issue on 56.0.2924.67 but not on latest Canary 58.0.2992.0.

The slowdown was due to continuously uploading large images to the GPU when re-rastering.  Improvements to caching images at display resolution may have fixed this.

ericrk@ I assume this is something too complex to try to get into M56?

M56 has already cut stable (unless they have to re-roll due to a large problem), so I don't think we can make that release.

I can't think of any changes in cached image size in the M56 > M58 range (those changes landed much earlier), so I'll need to poke around to figure out what did this.

Ah, OK, the change which improved this site was my patch to introspect/handle images in SkImageShaders. I don't think we can get this into 56, but it will be fixed in 57.

vmpstr@ - it appears that this same change has made SW raster performance worse in certain high-resolution retina cases.

If you use a MBP set to a retina resolution of 1920x1200, SW scroll performance becomes very bad. At this resolution, we need to raster the image at ~3840x2400. Because we now use mipmap downscales, and this is higher than 50%, we end up using the full image for SW (and doing a low-quality scale in Skia). The full-sized image is 5184x3456, and although we seem to keep it cached, it appears to take Skia a very long time to rasterize this image.

Not sure yet why this didn't bog-down the previous Skia path - maybe they weren't using mip-scaling in this case?

Note that when repro-ing, refresh the page until you get the piano background, this is the largest and shows the issue most clearly.

Deleted: trace_sw_raster_m_audio_piano_background_1920x1200_retina.json.gz 1.4 MB

trace_sw_raster_m_audio_piano_background_1920x1200_retina.json.gz 1.4 MB Download

hmm, from the looks of it, we're not actually intercepting the image. I think the sw performance problems come from the fact that we try to parallelize 4 tasks, but all of them get blocked on the same image decode. We avoid this problem in GPU, since there we only have one raster task. This seems to be exactly the type of issue that we want to fix using cc image decodes.

I'm going to investigate to see why these images aren't being captured.

Hmm, ignore that, I was on the wrong branch :) Still, it's interesting to see that without intercepting the image I could still reproduce really slow SW behavior.

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

commit 12976b2107b692819f81041ba8c15a033dae1940
Author: vmpstr <vmpstr@chromium.org>
Date: Tue Feb 07 19:57:18 2017

cc: Ensure to respect decoded filter quality adjustment in bg images.

This patch ensures that we pass through the decoded filter quality
adjustment from the image cache to skia.

R=ericrk@chromium.org
BUG= 660718 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2675373002
Cr-Commit-Position: refs/heads/master@{#448707}

[modify] https://crrev.com/12976b2107b692819f81041ba8c15a033dae1940/cc/playback/image_hijack_canvas.cc
[modify] https://crrev.com/12976b2107b692819f81041ba8c15a033dae1940/third_party/WebKit/LayoutTests/fast/borders/border-image-side-reduction-expected.png
[modify] https://crrev.com/12976b2107b692819f81041ba8c15a033dae1940/third_party/WebKit/LayoutTests/platform/linux/fast/borders/border-image-side-reduction-expected.png

It's a pretty simple change, so I'm going to request a merge but I'll watch out for problems in canary as well.

Your change meets the bar and is auto-approved for M57. Please go ahead and merge the CL to branch 2987 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

If possible, could you please merge your change to M57 branch 2987 before 5:00 PM PT today, Wednessday (02/08/17). thank you.

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

commit 0df20621cb824ff90921911600fa19a0e3fa570c
Author: Vladimir Levin <vmpstr@chromium.org>
Date: Wed Feb 08 21:07:36 2017

cc: Ensure to respect decoded filter quality adjustment in bg images.

This patch ensures that we pass through the decoded filter quality
adjustment from the image cache to skia.

R=ericrk@chromium.org
BUG= 660718 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2675373002
Cr-Commit-Position: refs/heads/master@{#448707}
(cherry picked from commit 12976b2107b692819f81041ba8c15a033dae1940)

Review-Url: https://codereview.chromium.org/2688503004 .
Cr-Commit-Position: refs/branch-heads/2987@{#394}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}

[modify] https://crrev.com/0df20621cb824ff90921911600fa19a0e3fa570c/cc/playback/image_hijack_canvas.cc
[modify] https://crrev.com/0df20621cb824ff90921911600fa19a0e3fa570c/third_party/WebKit/LayoutTests/fast/borders/border-image-side-reduction-expected.png
[modify] https://crrev.com/0df20621cb824ff90921911600fa19a0e3fa570c/third_party/WebKit/LayoutTests/platform/linux/fast/borders/border-image-side-reduction-expected.png

Verified the fix on Mac 10.12.2 using Chrome beta version #57.0.2987.54 as per the comment #0.

Observed that at URL: http://www.m-audio.com/products/browse/category/usb-audio-and-midi-interfaces, the scrolling was not slow and the scrolling happened without any issues.

Hence, the fix is working as expected.

Attaching the screencast for reference

Adding the verified labels.

Thanks...!!

Deleted: 660718.mp4 5.8 MB

	660718.mp4 5.8 MB View Download