Performance issue: Very slow/laggy scrolling on MacOS - "position:relative" and td elements - github url
Reported by
andryk...@gmail.com,
Feb 10 2018
|
|||||
Issue descriptionChrome Version : 64.0.3282.140 (Official Build) (64-bit) Operating System and Version: MacOS Sierra 10.12.6 URLs (if applicable) : https://github.com/OpenZWave/open-zwave/blob/master/cpp/src/Driver.cpp Description of performance problem: On some pages the scrolling is very slow with around 10 FPS. The URL above (github) is ~7000 lines long source code listing. The majority of the html is a table structure with 2 columns: - line number - <td> has CSS class .blob-num - source code line - <td> has CSS classes .blob-code and .blob-code-inner I found out that turning off the CSS property "position: relative" for class ".blob-code" fixes the problem and makes the scrolling fast and responsive again. The issue is not observed in other browsers. Attached trace files: trace_slow.json.gz - scrolling original page - low FPS trace_fast.json.gz - scrolling with the CSS change described above - high FPS Thanks, Andrew
,
Feb 12 2018
I can confirm this problem as well, and the associated fix. I've got a screencap of the issue here: https://drive.google.com/file/d/1QAQiir0Nns3BtTAQGrI24lOIWgsSqOxI/view?usp=sharing, and the link I used was this one: https://github.com/saltstack/salt/pull/22453/files As the video shows - the scrolling is fine until the rest of the diff is loaded dynamically. Then the performance craters. I'm in conversation with GitHub support who are also aware but haven't consistently been able to reproduce. My version is also Version 64.0.3282.140 (Official Build) (64-bit), but I'm on MacOS El Capitan 10.11.6.
,
Feb 13 2018
I can reproduce this on Canary (66.0.3344.0) and macOS 10.13.3. Here's a screen recording. Scrolling with the wheel hits 60FPS, scrolling with the bar tops out around 25 until I turn off position:relative for that element.
,
Feb 13 2018
Here's a trace, and a couple of screenshots of the trace.
,
Feb 13 2018
I can reproduce, and it's clear from the trace that we paint more stuff on a scrollbar-initiated scroll than we do on a wheel scroll, or a fling on the trackpad. Note that we paint just enough more stuff to flip over the frame budget and the frame rate halves due to vsync, presumably. Interestingly, if you turn on paint flashing in DevTools the slow performance goes away. I'm not an expert on scroll. What do we do differently in the compositor when it's a wheel or fling? I know this might come back to paint, where it seems our only way forward is to replicate the wheel/fling behavior.
,
Feb 13 2018
I can also reproduce that scrolling with a wheel (Mac magic mouse or Macbook trackpad) is slow and with the scrollbar is fast. Turning on paint flashing however doesn't resolve the issue for me.
,
Feb 15 2018
I'll take a look to find the reason of the performance difference between wheel scrolling and scrollbar scrolling.
,
Mar 3 2018
It seems like GitHub has changed the CSS so the issue is gone there but manually adding "position: relative" brings it back.
,
Aug 9
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by krajshree@chromium.org
, Feb 11 2018