Slow Scrolling on long pages when using mac trackpad with synergy
Reported by
jared.de...@gmail.com,
Aug 7 2017
|
||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 Example URL: Steps to reproduce the problem: 1. Enable the "Smooth Scrolling" flag (on by default) 2. Navigate to a long web page 3. Use a trackpad with momentum / acceleration 3. Scroll down very quickly What is the expected behavior? The page should scroll down very quickly. What went wrong? The scrolling seems to get chopped up into lots of short, slow scrolling bursts. This leaves the page lurching down slowly for several seconds after the action occurred. 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: 59.0.3071.115 Channel: stable OS Version: OpenSUSE Tumbleweed Flash Version: I use Synergy to share a Mac trackpad with a Linux desktop. Disabling the smooth scrolling flag fixes the issue and allows the page to scroll as quickly as the trackpad tells it to.
,
Aug 8 2017
Routing to Blink>Scroll. Can anyone triage this?
,
Aug 10 2017
After some more debugging, I am able to reproduce this even when smooth scrolling is disabled. The behavior seems to be caused by long pages with lots of content. Long empty pages do not exhibit the problem. Running a performance profile between the two types of pages indicates that the issue is that the "Update Layer Tree" activity is running on each scroll event and taking longer to complete than it takes the next scroll event to arrive. This causes a backlog of scroll events that get handled increasingly later than they arrived. I'm not sure how feasible it is to make this activity more performant, so it might be necessary to handle accumulated scroll events explicitly. Instead of queueing the events synchronously, the movement vectors should be added into a single scroll event. Synergy uses a similar strategy for accumulating mouse events, but it has no way of taking into account the latency introduced by Chrome's scroll handlers. Firefox does not have this issue. I can't immediately tell if it is because the activities triggered by the scroll event are faster, or if they are accumulating scroll vectors.
,
Aug 15 2017
Hotlist-ThreadedRendering please triage for "Update Layer Tree" performance issues.
,
Aug 16 2017
To get some tracing and scope of the issue ...
,
Aug 17 2017
re #10: Thanks for doing a performance check and noticing "Layer Tree Update". Are you able to record and attach aperformance trace as well. It will help us in identifying the issue quicker. Here is the instruction: https://www.chromium.org/developers/how-tos/submitting-a-performance-bug I recommend just having that one problematic tab open while recording the trace to ensure your recording does not include any potentially private data.
,
Aug 17 2017
Thank you for providing those instructions. I used a massive GitLab diff for this trace. (https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/12069/diffs)
,
Aug 21 2017
petermayo@: Could you please help in investigation of the attached trace.
,
Aug 24 2017
,
Apr 12 2018
It seems this might be better on someone else's queue.
,
Apr 12 2018
It looks like this was fixed sometime in the last 8 months, because I can no longer reproduce it. When I scroll quickly on large complex pages it does not get bogged down. I notice occasional frame drop where the page scroll "animation" fails to render for a few hundred milliseconds, but when it renders the next frame it jumps to where the page scroll position should have been given the real time that passed. Thanks for looking into this. |
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by nyerramilli@chromium.org
, Aug 8 2017