1502026 - Buy iPhone page animation seems janky

Status: RESOLVED FIXED

(Core :: DOM: Animation, defect, P3)

Description

[Andrew Overholt [:overholt]]

https://www.apple.com/ca/shop/buy-iphone/iphone-xs has an animation of phone images sliding into a "stack". Then, some details about the models including name and price and a blue "Select" button fades in. When that latter fade-in happens, the former image-sliding animation gets janky.

Comment 1

[Andrew Overholt [:overholt]]

I can reproduce on Windows with and without Web Render and we tried it on a Mac, too, and it was janky there.

Comment 2

[Brian Birtles (:birtles, Feb 26~ parental leave)]

This appears to be because of bug 1301305.

Specifically, the stack of phones are animated using transform animations but we don't run them on the compositor because there is a transition of 'height' that starts at the same time, and we try to synchronize geometric animations that start at the same time.

We don't want to drop that behavior or the animation on trello.com looks worse but maybe there's some way we can tweak the heuristic so that we don't apply it to this site but continue to apply it to trello.com.

One option might be to not synchronize CSS animations and CSS transitions--they tend to be used in different ways suggesting that even if they happen to start at the same time they probably aren't expected to be synchronized. That would happen to fix this site, I think, but this site could also have been created entirely using CSS transitions in which case it wouldn't help.

Other than that, I'm not sure. Maybe it's worth trying the transitions vs animations distinction. Let me see if I can look at it next week.

(For what it's worth, Google are considering adding the same "synchronize all the geometric animations" heuristic we have to Chrome in which case they will hit this same issue. Authors really just shouldn't animate properties that trigger re-layout and expect it to be smooth--and especially not on a massive hero element.)

Comment 3

[Hiroyuki Ikezoe (:hiro)]

Yeah, I think it's worth a shot.

Comment 4

[Brian Birtles (:birtles, Feb 26~ parental leave)]

Hiro mentioned that he was saw the following warning in the console:

`Animation of ‘transform’ cannot be run on the compositor because it should be synchronized with animations of geometric properties that started at the same time [image with id 'tracking-protection-icon-animatable-image']`

I'm guessing that the transform CSS animation was being blocked by this transition:

  https://searchfox.org/mozilla-central/rev/fc3d974254660b34638b2af9d5431618b191b233/browser/themes/shared/identity-block/identity-block.inc.css#163-165

If so, the strategy of only synchronizing CSS transitions with CSS transitions, and other animations with other animations might fix this case too.

Comment 5

[Brian Birtles (:birtles, Feb 26~ parental leave)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=07d02372869ce2c96e59772bc6618b31a5f170e2

Looking at the animation inspector this seems to fix the issue but I'm honestly having a hard time reproducing the jank on this fairly fast machine.

Comment 6

[Brian Birtles (:birtles, Feb 26~ parental leave)]

Attachment: Bug 1502026 - Only synchronize CSS transitions with CSS transitions; r?hiro

For some content both transitions and animations are triggered simultaneously.
As a result of bug 1301305, if the set of animations includes animations that
affect geometry, then we ensure that any transform animations are run on the
main thread, rather than on the compositor.

However, we have observed some content where this synchronizing is not necessary
and produces unnecessary jank. In the particular cases we have observed,
the transitions and animations do not need to be synchronized so this patch
refines the approach from bug 1301305 to only synchronize within the set of CSS
transitions or the set of non-transition animations.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/60082f8c23b4
Only synchronize CSS transitions with CSS transitions; r=hiro

Comment 8

[Eliza Balazs [:ebalazs_]]

https://hg.mozilla.org/mozilla-central/rev/60082f8c23b4

Comment 9

[Andrew Overholt [:overholt]]

Today's nightly (about:buildconfig says it was built from https://hg.mozilla.org/mozilla-central/rev/182a1b088330a2d72310ae2561004d955571e236) is still slightly janky when the "Select" button fades in. But it seems smoother overall :)

Comment 10

[Brian Birtles (:birtles, Feb 26~ parental leave)]

(In reply to Andrew Overholt [:overholt] from comment #9)
> Today's nightly (about:buildconfig says it was built from
> https://hg.mozilla.org/mozilla-central/rev/
> 182a1b088330a2d72310ae2561004d955571e236) is still slightly janky when the
> "Select" button fades in. But it seems smoother overall :)

Yeah, it definitely still janks. It appears to happen when the scroll bar changes length so I think there's something else going on there (which is less likely to be an animation issue).

Needinfoing me for now so I can try to have another look later in the week (on PTO today).