This sounds like a chromium bug, not a v8 one; moving it to the chromium tracker for further triage.

Moved issue v8:7319 to now be  issue chromium:802819 .

sahel@ can you please investigate?

What I saw was regression in responsiveness rather than scrolling issue, I also saw the regression on Canary with wheel scroll latching and async wheel events disabled.

I have attached the trace from Canary. Looks like the compositor is busy doing long tasks (e.g DecodingImageGenerator::getPixels, ImageFrameGenerator::decodeAndScale). 

Deleted: trace_Canary_65_busy_compositor.json.gz 1.5 MB

trace_Canary_65_busy_compositor.json.gz 1.5 MB Download

It looks like it's spending all its time in GpuImageDecodeCache::GetDecodedImageForDraw -> GpuImageDecodeCache::UploadImage - color conversion

Something wrong with the image cache maybe?

taking a look.

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

commit ec5246d62d67feb1992c0fc61add8160f5b5309c
Author: Eric Karl <ericrk@chromium.org>
Date: Mon Jan 22 22:50:26 2018

Adjust purging of unlocked discardable in GPU Image Decode Cache

We were incorrectly purging unlocked discardable to "make room" in the
cache, although unlocked entries don't take up room. This resulted in
non-optimal cache purging when we hit at-raster scenarios.

Now that all cached items are discardable, this change removes all
purging other than that needed to handle our max items in cache limit.

Bug:  802819 ,  804328 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel
Change-Id: I5cece605bbd40283073c075e78b36867c8c7efbf
Reviewed-on: https://chromium-review.googlesource.com/879064
Commit-Queue: Eric Karl <ericrk@chromium.org>
Reviewed-by: Khushal <khushalsagar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#531032}
[modify] https://crrev.com/ec5246d62d67feb1992c0fc61add8160f5b5309c/cc/tiles/gpu_image_decode_cache.cc
[modify] https://crrev.com/ec5246d62d67feb1992c0fc61add8160f5b5309c/cc/tiles/gpu_image_decode_cache_unittest.cc

Would like to merge #8 to M65 to address this M64 regression. I don't think this is serious enough to warrant an M64 merge, as it only impacts perf when we've already hit the low-performance "at-raster" image decode path, but open to other opinions here.

How is the change listed at #8 looking in canary? 

Tested this issue on Windows 10, Mac OS 10.12.6 and Ubuntu 14.04 on the latest Chrome build 66.0.3330.0 and below are the observations..

- On Windows 10 and Ubuntu 14.04, Can scroll smoothly through the given html page and no issues are observed while scrolling.
- On Mac OS, not able to scroll smoothly through the page and can observe blank spaces while scrolling.
Attached are the screen casts for reference.

ericrk@ Can you please check and verify if this fix is working as intended or no. 

Thanks..

Deleted: 802819_latestCanary.webm 11.7 MB

	802819_latestCanary.webm 11.7 MB View Download

Deleted: 802819_Mac.webm 5.2 MB

	802819_Mac.webm 5.2 MB View Download

There's an additional fix needed for the remaining mac issue that I was going land later (and request to merge separately). But I assume there's no rush for M65 (assuming I land the second fix in the next few days). Let me land that and we can confirm / merge both?

dropping merge-request. Will re-add it when both fixes are landed.

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

commit 79c2946a9bb6b480e623a16ed2a3bea9e87c92f1
Author: Eric Karl <ericrk@chromium.org>
Date: Sat Jan 27 07:19:28 2018

Perform colorspace conversion for SW images in GPU cache at decode time

When caching very large images in the GPU image decode cache,
we don't upload to the GPU, but instead just cache the CPU side data
for re-use. Unfortunately, we currently perform color conversion post
upload, which means that, in the SW-only case, we end up re-converting
images on every use.

This patch causes SW-only cache entries to have their color conversion
done at decode time, ensuring we persist it in the cache.

Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel
Change-Id: I26831b119dffff09f977567631dd2dc7e99e7978
Bug:  802819 
Reviewed-on: https://chromium-review.googlesource.com/877106
Commit-Queue: Eric Karl <ericrk@chromium.org>
Reviewed-by: Khushal <khushalsagar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#532185}
[modify] https://crrev.com/79c2946a9bb6b480e623a16ed2a3bea9e87c92f1/cc/paint/paint_image.cc
[modify] https://crrev.com/79c2946a9bb6b480e623a16ed2a3bea9e87c92f1/cc/tiles/gpu_image_decode_cache.cc
[modify] https://crrev.com/79c2946a9bb6b480e623a16ed2a3bea9e87c92f1/cc/tiles/gpu_image_decode_cache.h
[modify] https://crrev.com/79c2946a9bb6b480e623a16ed2a3bea9e87c92f1/cc/tiles/gpu_image_decode_cache_unittest.cc

Re-adding merge request now that both fixes have landed. Would like to merge CLs in comment #8 and #15 to M65 to address an M64 regression and an M65 regression. The M65 regression is a bit worse (leads to very poor scrolling on certain sites, like the one linked in this bug).

Confirmed that these changes address the issue in Canary.

Your change meets the bar and is auto-approved for M65. Please go ahead and merge the CL to branch 3325 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

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

Thank you for the rapid progress here.  I've been following each update with great interest.

tim@, thanks for reporting this bug! Glad we were able to come up with a fix.

FYI, while Chrome displays your site reasonably well with the above patches applied, your site does stress our large image path a bit. In the second set of diffs on the test site there are three very large images which are simultaneously displayed. These images take up 155MB+76MB+76MB=307MB when decoded at display resolution. This exceeds our normal cache limits (and GPU max texture sizes), making us hit less optimal paths.

While there's future work Chrome may be able to do to address this (splitting up large images into chunks for display), this is likely a ways out. I don't know how difficult this is to achieve for your app, but if simple, splitting up images into chunks with 8k max dimensions may increase performance for your site.

Either way, thanks for the report!

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

commit 7845c4435ff562dd058ec2af0d7269d73abce7a7
Author: Eric Karl <ericrk@chromium.org>
Date: Tue Jan 30 18:38:17 2018

Adjust purging of unlocked discardable in GPU Image Decode Cache

We were incorrectly purging unlocked discardable to "make room" in the
cache, although unlocked entries don't take up room. This resulted in
non-optimal cache purging when we hit at-raster scenarios.

Now that all cached items are discardable, this change removes all
purging other than that needed to handle our max items in cache limit.

TBR=ericrk@chromium.org

(cherry picked from commit ec5246d62d67feb1992c0fc61add8160f5b5309c)

Bug:  802819 ,  804328 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel
Change-Id: I5cece605bbd40283073c075e78b36867c8c7efbf
Reviewed-on: https://chromium-review.googlesource.com/879064
Commit-Queue: Eric Karl <ericrk@chromium.org>
Reviewed-by: Khushal <khushalsagar@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#531032}
Reviewed-on: https://chromium-review.googlesource.com/893428
Reviewed-by: Eric Karl <ericrk@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#174}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[modify] https://crrev.com/7845c4435ff562dd058ec2af0d7269d73abce7a7/cc/tiles/gpu_image_decode_cache.cc
[modify] https://crrev.com/7845c4435ff562dd058ec2af0d7269d73abce7a7/cc/tiles/gpu_image_decode_cache_unittest.cc

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

commit 74c72c093cfa30c26f13ab9baa546845c3d1760d
Author: Eric Karl <ericrk@chromium.org>
Date: Tue Jan 30 18:44:55 2018

Perform colorspace conversion for SW images in GPU cache at decode time

When caching very large images in the GPU image decode cache,
we don't upload to the GPU, but instead just cache the CPU side data
for re-use. Unfortunately, we currently perform color conversion post
upload, which means that, in the SW-only case, we end up re-converting
images on every use.

This patch causes SW-only cache entries to have their color conversion
done at decode time, ensuring we persist it in the cache.

TBR=ericrk@chromium.org

(cherry picked from commit 79c2946a9bb6b480e623a16ed2a3bea9e87c92f1)

Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel
Change-Id: I26831b119dffff09f977567631dd2dc7e99e7978
Bug:  802819 
Reviewed-on: https://chromium-review.googlesource.com/877106
Commit-Queue: Eric Karl <ericrk@chromium.org>
Reviewed-by: Khushal <khushalsagar@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#532185}
Reviewed-on: https://chromium-review.googlesource.com/893650
Reviewed-by: Eric Karl <ericrk@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#176}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[modify] https://crrev.com/74c72c093cfa30c26f13ab9baa546845c3d1760d/cc/paint/paint_image.cc
[modify] https://crrev.com/74c72c093cfa30c26f13ab9baa546845c3d1760d/cc/tiles/gpu_image_decode_cache.cc
[modify] https://crrev.com/74c72c093cfa30c26f13ab9baa546845c3d1760d/cc/tiles/gpu_image_decode_cache.h
[modify] https://crrev.com/74c72c093cfa30c26f13ab9baa546845c3d1760d/cc/tiles/gpu_image_decode_cache_unittest.cc

@Eric thanks for the info!  We'll look at making some improvements to split larger images in the future too.

I've just tried the latest Chrome Canary, and it's dramatically improved.  Thank you!

I'm witnessing degraded scrolling performance with large images again. Did this bug creep back into newer versions of Chrome? Also happens on Chrome/Android on my Pixel 2.

Note that I'm talking about really large images (900px x 20,000px).

Scrolling performance is great in Safari.

re #25: Please file a new bug with an example URL and we can look at it there.