1537714 - When .on("click") toggleClass : CSS "Transform" animation lag

Status: NEW

(Core :: CSS Transitions and Animations, defect, P3)

Description

[Kaël Gustin-Hiron]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

• Click on a burger menu in mobile to show an overlay menu sliding from the right

Actual results:

• Overlay menu animation ( transform: translateX(100%) to transform: translateX(0) ) very slow with lag
• lag on the button himself when clicking ( transform: scale(1) to transform: scale(0.9) )

Expected results:

• scale smoother when clicking on the button (like in Chrome for android)
• slide smoother when clicking on the burger button (like in Chrome for android)

Comment 1

[Emilio Cobos Álvarez [:emilio]]

Do you have an URL or a test-case we could reproduce this problem with?

Comment 2

[Kaël Gustin-Hiron]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #1)

Yes in my personal website for example : https://kaelgh.com
Sorry but I can't give you the second example I have because it's a website in developpement in my company.

Maybe this bug/lag appears when the "transform" animation come at the same time of a seconde animation.
On my website (and the other private example) when you click on the burger, there are two "transform" animation:

• one on the menu (sliding, or on my website, scaling)
• one on the burger (scaling, or on my website the bars of the burger that transform themself)

There is another example using "transform" animation with just one transformation for the menu and there is no bug/lag : https://kaelgh.com/mmi/s4/scss/take

Thanks for your reply

Comment 3

[Emilio Cobos Álvarez [:emilio]]

Thanks, I think I can sort of reproduce it on my phone. Looks like we're probably not layerizing correctly the first time, since lag only happens the first time you touch the menu.

Can you test if adding will-change: transform to the animating pseudo-element avoids the lag? Just to confirm before sending the bug to the graphics folks :)

Comment 4

[Kaël Gustin-Hiron]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)

I update my code with will-change: transform and there si nothing new. And for me is not only at the first time, even if the first animation is more "laggy" than the others.

I tried to update the css in my other project (for my company) and it didn't change anything. You can visit this website at : https://vigilock.github.io/consignity.fr/

Maybe the probleme came from the cubic-bezier function used for the transformation : transition : transform 0.5s cubic-bezier(0.165, 0.84, 0.44, 1) ?!

Thx
Kaël

Comment 5

[Emilio Cobos Álvarez [:emilio]]

Alright, I see it now, I wasn't seeing it the first time because I had WebRender enabled.

Profile without WebRender just shows a bunch of time rasterizing.

Brian / Hiro / Boris, do you know why this animation isn't running on the compositor? I would expect no main-thread painting to be going on on this animation, but here's the profile that I get:

https://perfht.ml/2Tsl5Tw

Comment 6

[Boris Chiou [:boris]]

Just borrowed an Android device and still checking why it doesn't run on the compositor.

However, when I clicked the burger button in https://kaelgh.com, I saw this NS_ASSERTION [1]:

[9549, Main Thread] ###!!! ASSERTION: Unexpected UpdateTransformLayer hint: '!(aChange & nsChangeHint_UpdateTransformLayer) || aFrame->IsTransformed() || aFrame->StyleDisplay()->HasTransformStyle()', file /Users/chiahunglin/mozilla/gecko/layout/base/RestyleManager.cpp, line 1206

This might be a different bug, and it didn't happen in https://kaelgh.com/mmi/s4/scss/take.

[1] https://searchfox.org/mozilla-central/rev/4eaf7c637a303e0f7adcf1ae45064b2d4bef9eb0/layout/base/RestyleManager.cpp#1195-1199

Comment 7

[Emilio Cobos Álvarez [:emilio]]

FWIW, it runs quite slow on Desktop too (without WR at least)

Comment 8

[Hiroyuki Ikezoe (:hiro)]

I think that's because the layer size is too big. On WebRender we no longer have the restriction, sotaro did it in bug 1508522.

Comment 9

[Boris Chiou [:boris]]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #8)

I think that's because the layer size is too big. On WebRender we no longer have the restriction, sotaro did it in bug 1508522.

Yes. I checked it by devtool. We got two kinds of performance warnings:
When clicking the burger

1. CompositorAnimationWarningContentTooLargeArea (main reason, I think. For the overlay menu.)
2. CompositorAnimationWarningTransformWithSyncGeometricAnimations (On the upper-right icon, there is also an animation on top property.)

Click again on the "X" button

1. CompositorAnimationWarningTransformWithSyncGeometricAnimations

Comment 10

[Kaël Gustin-Hiron]

Do you think that in the future, in general, I should focus on 3D transformations (such as transform: translate3D()) to force the activation of GPU acceleration rather than continue to use simple transform? And wouldn't that solve my problem on my two sites presented?

Thx for your reply

Kaël

Comment 11

[Kaël Gustin-Hiron]

...or better use translateZ(0) or perspective as a trigger of GPU usage ?

Comment 12

[Hiroyuki Ikezoe (:hiro)]

(In reply to Kaël Gustin-Hiron from comment #10)

Do you think that in the future, in general, I should focus on 3D transformations (such as transform: translate3D()) to force the activation of GPU acceleration rather than continue to use simple transform? And wouldn't that solve my problem on my two sites presented?

Right, unfortunately, using transform3D doesn't solve the issue at all. We need to fix bug 1100357. If the element size by the transform animation can be smaller, the transform animation in question might run on the compositor.

Comment 13

[Brian Birtles (:birtles)]

For the CompositorAnimationWarningTransformWithSyncGeometricAnimations component, we need to investigate limiting the optimization that tries to synchronize animation of geometric properties (forcing them to run on the main thread) but for now it might be worth trying to remove the animation of 'top' from the content. That should at least allow the close animation to run on the compositor.

Comment 14

[Boris Chiou [:boris]]

(In reply to Boris Chiou [:boris] from comment #9)

Click again on the "X" button

1. CompositorAnimationWarningTransformWithSyncGeometricAnimations

Sorry, there is also a warning, CompositorAnimationWarningContentTooLargeArea, on the closing overlay menu when clicking the close button. (It's too fast on the desktop so I missed it.)

If there is a lag on the "button" himself when clicking, I think Brian's suggestion is worth to try.

Comment 15

[Hiroyuki Ikezoe (:hiro)]

I did mis-recognize that this is related to the larger layer issue (bug 1100357), actually it's not related to.