Issue metadata
Sign in to add a comment
|
SVG scrolling performance
Reported by
vorcak....@gmail.com,
Jan 16 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 Steps to reproduce the problem: 1. Place some complex SVGs to a scrollable div Have a look at http://stackoverflow.com/questions/34824098/why-is-svg-scrolling-performance-so-much-worse-than-png Try to reproduce using jsfiddle - it's reproducible here https://jsfiddle.net/6em5sm5q/ What is the expected behavior? What went wrong? Scrolling of a div with SVGs is much much slower, it works fine on Opera for instance. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 55.0.2883.95 Channel: stable OS Version: OS X 10.12.2 Flash Version: Shockwave Flash 24.0 r0 I've tried to search for a possible duplicate, but I was not 100% sure if the bug is duplicate of something. Sorry if it already exists. I just felt there should be a bug reported for SO thread.
,
Jan 17 2017
Could you please check and confirm if its same as 342778.
,
Jan 17 2017
It seems like it's the same issue.
,
Jan 17 2017
From a quick trace on my Chromebook pixel I see many 50ms OneCopyRasterBuffer::Playback tasks on CompositorTileWorker thread. Other than the scrollbar (which is the same for SVG and PNG) I don't see any paint flashing during scroll. So someone on the CC team should probably take a look, right?
,
Jan 17 2017
From an unscientific eyeballing I see similar jank on Chrome and Safari on Mac, but not on Firefox which seems smooth. On Windows Chrome I see a fair amount of white flashing while scrolling. Edge behaves similarly except the missing rasterization is less jarring because it always fills in in order. Doesn't seem like an obvious performance interop issue, but still worth investigating if there's any low hanging fruit here?
,
Jan 17 2017
This is not unexpected. Because SVG Image is required to respect percentage lengths and the like, we do layout each time it is painted, even if it is the same SVG image painted over and over. This is expensive when you are painting a lot of SVG images. The solution in this case is to get the scroller composited, which can be done by setting an opaque background color in Chrome 56 and later. At least in theory. I could not get the scroller composited regardless.
,
Jan 17 2017
Re #6, the scroller also requires contain: paint - see issue 666147 .
,
Jan 18 2017
This is a non-regression issue since 35.0.1849.0, hence untriaged as Non-regression.
,
Jan 18 2017
Should we follow up on SO? Fixing http://crbug.com/472129 will fix the problem forever, but that's a big re-factoring.
,
Mar 24 2018
,
Jun 4 2018
I've reported the same thing in the past and was marked as "won't fix", see: https://bugs.chromium.org/p/chromium/issues/detail?id=342778 for more context, and more test cases. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by ajha@chromium.org
, Jan 17 2017