Slow desktop scroll performance - fast mobile emulated scroll performance
Reported by
larsoles...@gmail.com,
Jan 5 2017
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2971.0 Safari/537.36 Steps to reproduce the problem: 1. Go to http://jsfiddle.net/sg5yowq4/1/ 2. Scroll up and down in bottom right result area when it has rendered 3. Observe scroll jank What is the expected behavior? Smooth scrolling. What went wrong? Scroll jank Did this work before? N/A Chrome version: 57.0.2971.0 Channel: canary OS Version: 10.0 Flash Version: Shockwave Flash 24.0 r0 Curiously, the problem goes away if I enable mobile emulation. Also, in ms edge, there is no issue scrolling the same grid (see attached screenshots). The same happens in chrome stable on windows (55.0.2883.87) as well as on OSX (55.0.2883.95). Apologies if this is a duplicate. I saw many existing scroll related issues, but none that precisely cover my observations.
,
Jan 6 2017
,
Jan 6 2017
Tested on Windows 10 , Mac OS 10.12.2 , Ubuntu 14.04 using chrome Canary M57 #57.0.2973.0 and issue is reproduced. Issue is seen from M50 and from M30 to M49 , the given js fiddle content is not loaded completely. Hence , it is a non-regression issue , marking it as untraiged. Thanks!
,
Jan 12 2017
Given the difference between high and low DPI screens, it sounds like on low DPI we don't promote the scroller to a composited layer so we're scrolling on the main thread. This is expected since on low DPI screens, promoting a scroller to be composited would lose LCD text anti-aliasing and make text look worse. This would also explain why turning on mobile emulation helps. On Android we always promote scrollers since most Android devices are high DPI and low performance. Try running chrome with --enable-prefer-compositing-to-lcd-text and see if that helps. Aside from that, you can force your scroller to composite *and* keep LCD text by adding an opaque background and `contain: paint`. `will-change: transform` should also work but you'll lose LCD text as I mentioned above.
,
Jan 12 2017
,
Jan 19 2017
Closing due to explanation in #4. Feel free to comment if I'm missing something.
,
Jan 20 2017
The suggested 'will-change: transform' workaround does seem to address the issue. I haven't yet spotted the mentioned anti-aliasing issues. I'm having no luck with the 'opaque background and contain: paint' approach. It would be nice if the linked fiddle could be updated to illustrate the workarounds, I guess. I'm happy with the existence of a workaround that allows me to get hardware accelerated scrolling.
,
Jan 20 2017
Ah, my bad, the opaque+contain:paint approach is a recent optimization that's shipping in M56 so you wouldn't see it in stable channel yet. LCD text antialiasing is quite subtle so it's easy to miss but it can really make a difference on long text pages to eye fatigue. http://bokand.github.io/lcdtext.html tries to show the difference - though it's not easy to notice even when you're looking for it. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by larsoles...@gmail.com
, Jan 5 2017