touch-action:manipulation on large number of elements has huge performance hit
Reported by
splinte...@gmail.com,
Jan 9 2018
|
|||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36 Steps to reproduce the problem: 1. Open a document which contains a large number of elements that have been given a CSS style of "touch-action:manipulation" 2. Note that the document behaves extremely sluggishly when interacting with it. Clicks, keyboard entry (e.g. on inputs), animations, even core browser functionality like context menu ... everything is severely impacted 3. There are further reports (see https://github.com/twbs/bootstrap/issues/24670#issuecomment-356340395) that this even has an impact on loading times (or it's simply the result of all the thrashing resulting in an overall slowdown on all activities, such as loading?) What is the expected behavior? while touch-action likely results in increased hit testing, I wouldn't have expected such a severe impact. What went wrong? touch-action seems to cause a severe performance hit (which becomes obvious on large documents) on the main thread. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 63.0.3239.132 Channel: stable OS Version: 10.0 Flash Version:
,
Jan 10 2018
Able to reproduce this issue on reported version 63.0.3239.132, on latest canary 65.0.3117.0 using Windows 10,Ubuntu 14.04 and Mac 10.13.1 with attached html file. i.e; Scrolling,opening context menu and inputing is very sluggish. This issue is seen from M50[50.0.2661.0]. Hence considering this issue as Non-Regression and marking as Untriaged.
,
Jan 11 2018
,
Jan 11 2018
A trace indicates that computing the touch-action in the scrolling coordinator takes like 8.2s. So it is quite slow.
,
Jan 17 2018
,
Apr 1 2018
A performance issue which from the outside looks similar to the one mentioned in the comments of issue 605419 , so I wonder if both of these issues could be tackled at the same time.
,
Sep 14
We have code that is supposed to stop accumulating touch action rects and union them all once we get to 100, see use of kMaxRectsPerLayer. Can you investigate why we slow down on large numbers of touch action elements? We should have this fixed upper bound for number of elements to process, if we continue to do work for more elements there must be a bug.
,
Sep 21
This will be fixed once PaintTouchActionRects is shipped. If you run canary channel with --enable-blink-features=PaintTouchActionRects, it is as smooth as Firefox. This feature will be ship very soon.
,
Sep 21
PaintTouchActionRects is now shipped and will be available on tmr's canary channel.
,
Sep 25
Re-open because we revert the ship of PaintTouchActionRects
,
Nov 26
PaintTouchActionRects has been shipped |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by krajshree@chromium.org
, Jan 10 2018