visibility: hidden animation doesn't stop painting |
|||||
Issue descriptionVersion: m51 OS: All, presumably What steps will reproduce the problem? This was noticed on Google Keep. They have a load spinner that they hide using visibility: hidden that still uses 20-50% of the CPU due to layout and layer tree updates and so on. What is the expected output? Non-visible elements should not cause an otherwise static page to use a lot of CPU. What do you see instead? Lots of CPU usage that disappear when the visibility: hidden is changed to display: none. The spinner in question is the standard Material Design spinner. The team want to use visibility to control the display because it can be animated. It seems like we should be able to update the animation without doing layout or going through the effort of repainting the page. I'll try to generate a small repro.
,
May 19 2016
,
May 19 2016
I agree that we don't want to stop the animations (there's a bug about the problems with that in hidden iframes), but we still don't need to paint them, which seems to be causing a lot of work in the traces I was looking at.
,
May 19 2016
Ah I see. Yes we can avoid paint. Thanks for clarifying.
,
May 19 2016
,
Jul 9 2016
Moving this nonessential bug to the next milestone. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 13 2017
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by chrishtr@chromium.org
, May 19 2016