1337395 - An animation on "transform" in a big page is slow

Status: RESOLVED WORKSFORME

(Core :: Web Painting, defect)

Description

[Julien Wajsberg [:julienw]]

Attachment: deezer.zip

STR:
1. Unzip the attachment
2 [review]. Load the attachment in Firefox
3. Look at your "top"

=> On my machine this is near 100%.

Here is a profile: https://clptr.io/2kOs8YU

I tried to slim down the attachment but when I remove things, this is less visible. Therefore I believe there is something related to the size of the DOM tree.

The core issue is the "equalizer" animation we see on the "best of grunge" cover (left of the window). Once I disable the animations there is no more issue.

This comes from deezer.com, a spotify-like service on the web. They decided to use a gif moving forward because of this.

Comment 1

[Julien Wajsberg [:julienw]]

I realise that an animation on a transform avoid a relayout but doesn't avoid the restyle. Here the restyle seems to be slow.

What is strange though is that on a profile in Firefox (not Cleopatra) I didn't find much difference between this page and a very minimal page with the same animations. I'll upload the minimal page tomorrow as a reference (I don't have it here).

Comment 2

[Hiroyuki Ikezoe (:hiro)]

FWIW, if the animation is on a large layer, it might be bug 1100357.  If the animation is in visibility:hidden element, it might be bug 1237454.

Comment 3

[Julien Wajsberg [:julienw]]

I don't think this is either case.

Comment 4

[Xidorn Quan [:xidorn] UTC+10]

From the profile, it seems the majority of time is spent in building the display list?

Comment 5

[Timothy Nikkel (:tnikkel)]

Can we get the equivalent testcase with an animated gif to compare why it is better?

Comment 6

[Julien Wajsberg [:julienw]]

Here is a profile without the animation, and without the animated gif: https://clptr.io/2kKGnhe

Comment 7

[Julien Wajsberg [:julienw]]

Here is a new profile with the CSS animation, with latest nightly: https://clptr.io/2kZXxWy
It seems better than previously measured (~50% of my CPU).

And here is a profile without the CSS animation, with the animated gif (~12% of my CPU): https://clptr.io/2kKJu8F

FWIW it's less pleasing aesthically with the animated gif, the CSS animation is much smoother.

Comment 8

[Jet Villegas (inactive)]

(In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #4)
> From the profile, it seems the majority of time is spent in building the
> display list?

Adding as a dependency of bug 1204549

Comment 9

[Timothy Nikkel (:tnikkel)]

(In reply to Julien Wajsberg [:julienw] from comment #7)
> Here is a new profile with the CSS animation, with latest nightly:
> https://clptr.io/2kZXxWy
> It seems better than previously measured (~50% of my CPU).
> 
> And here is a profile without the CSS animation, with the animated gif (~12%
> of my CPU): https://clptr.io/2kKJu8F
> 
> FWIW it's less pleasing aesthically with the animated gif, the CSS animation
> is much smoother.

Okay, so the reason for the difference is probably just that we are building the displaylist at 60fps for the CSS animation vs a much lower framerate for the animated gif. The display list building is too slow in both cases.

Comment 10

[Miko Mynttinen]

Julien, can you still reproduce this? With the latest Nightly, I get steady 60 FPS on my MBP with around 10-15% CPU usage. Also the display list creation times seem to be reasonable.

Profile: https://perfht.ml/2mFqjLc
Profile with continuous scrolling: https://perfht.ml/2mFDP1r

Comment 11

[Julien Wajsberg [:julienw]]

Yeah, I agree with you.

From my tests, 51 and 52 are affected, 53 (Beta), 54 (Aurora) and 55 Nightly are not.
I'm especially surprised by the result in Beta -- do you have an idea what could have changed this ?

Comment 12

[Miko Mynttinen]

(In reply to Julien Wajsberg [:julienw] from comment #11)
> Yeah, I agree with you.
> 
> From my tests, 51 and 52 are affected, 53 (Beta), 54 (Aurora) and 55 Nightly
> are not.
> I'm especially surprised by the result in Beta -- do you have an idea what
> could have changed this ?

According to mozregression, the changes in bug 1275347 seem to make display list measurements more accurate, almost halving their duration. Presumably some changes during the last month also improved display list invalidation during animation, since I can't see it getting triggered like in your older profiles.

I also tried reproducing this on Windows 10, the CPU usage with Lenovo P50 was around 1-2%.