New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 597678 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 381840
Owner: ----
Closed: Mar 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

Poor scrolling performance with overflow-y: auto

Reported by a...@scirra.com, Mar 24 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2689.0 Safari/537.36

Example URL:
https://dl.dropboxusercontent.com/u/15217362/bugs/scrollperf/slow.html

Steps to reproduce the problem:
Test URL: https://dl.dropboxusercontent.com/u/15217362/bugs/scrollperf/slow.html

1. Scroll the number list.
2. Observe performance visually. (Also try recording a timeline while scrolling.)

What is the expected behavior?
This is all static content, so it should scroll perfectly smoothly.

What went wrong?
Chrome's scrolling performance is terrible. I recorded a timeline and on a high-end dev machine it's spending 9ms in "scroll" and 55ms in "Update Layer Tree" (!) per frame (!!).

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? Yes 

Chrome version: 51.0.2689.0  Channel: canary
OS Version: 10.0
Flash Version: Shockwave Flash 21.0 r0

Both Firefox and Edge handle this case perfectly smoothly, so this performance problem is exclusive to Chrome.

Also compare to this case which runs fast in Chrome as well: https://dl.dropboxusercontent.com/u/15217362/bugs/scrollperf/fast.html

The *only* change is removing overflow-y: scroll. This means the main window viewport scrolls instead, and that is perfectly smooth. So there's nothing about scrolling the content that is demanding, Chrome is entirely capable of doing it fast, it's just super slow in a scroll container.
 

Comment 1 by a...@scirra.com, Mar 25 2016

Note I tried a hi-dpi laptop and the slow.html case is actually still fast. I don't know if it's really dpi related, but it does seem somehow system-specific.
Components: -Blink Blink>Scroll

Comment 3 by bokan@chromium.org, Mar 31 2016

Cc: vollick@chromium.org
Components: Blink>Compositing
Labels: -OS-Windows OS-All
Status: Untriaged (was: Unconfirmed)
This is because we don't promote the scrolling content to a compositor layer due to being low-DPI (and thus losing LCD text antialiasing). You can force this into a compositor layer by applying a transform on the scroller:

transform: translateZ(0)

This fixes the performance issue but may degrade text quality on lowDPI devices.

I've attached a trace of the scroll.

+vollick@, is there a tracking bug we can Dup into for these "should fast scrolling but cant" cases?
slow_scroll_trace.json.gz
3.0 MB Download

Comment 4 by a...@scirra.com, Mar 31 2016

Firefox can do both fast-scrolling and LCD text antialiasing in this case. Do we have to choose between high-quality text and good performance in Chrome? If so, which should we choose...?
Mergedinto: 381840
Status: Duplicate (was: Untriaged)

Sign in to add a comment