1506932 - Page transitions are not super smooth

Status: NEW

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

Description

[Andreas Bovens [:abovens]]

1. Go to https://page-transitions.com/group
2. Click on the three dots in the top right corner
3. Pick one of the three links shown in the menu

Expected result:
Page transition is smooth.

Actual result:
Page transition stutters somewhat (compare with Chrome). The effect is worse on Firefox for Android, incl. GeckoView.

Comment 1

[Hiroyuki Ikezoe (:hiro)]

The animation seems not a CSS animation/transition.  Looks like style changes driven by requestAnimationFrame some such?  I can't see any animations in devtools animation inspector.

Comment 2

[Brian Birtles (:birtles)]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #1)
> The animation seems not a CSS animation/transition.  Looks like style
> changes driven by requestAnimationFrame some such?  I can't see any
> animations in devtools animation inspector.

That's odd. I see lots of transitions. Did you click one of the links?

Some of the transform transitions appear to be hitting the "synchronize geometric animations" optimization (bug 1301305) and hence are running on the main thread :(.

Comment 3

[Sean Voisen (:svoisen)]

(In reply to Brian Birtles (:birtles) from comment #2)

> Some of the transform transitions appear to be hitting the "synchronize
> geometric animations" optimization (bug 1301305) and hence are running on
> the main thread :(.

I was afraid that might be the case, so I asked Andreas to CC you. Sorry to hear my suspicions might be confirmed.

Comment 4

[Hiroyuki Ikezoe (:hiro)]

(In reply to Brian Birtles (:birtles) from comment #2)
> (In reply to Hiroyuki Ikezoe (:hiro) from comment #1)
> > The animation seems not a CSS animation/transition.  Looks like style
> > changes driven by requestAnimationFrame some such?  I can't see any
> > animations in devtools animation inspector.
> 
> That's odd. I see lots of transitions. Did you click one of the links?

No!  Sorry for confusing.

> Some of the transform transitions appear to be hitting the "synchronize
> geometric animations" optimization (bug 1301305) and hence are running on
> the main thread :(.

Yeah, that was my initial guess.

In the old animation inspector we can see warnings if the animation can not be run on the compositor, but now we can no longer see it?

Comment 5

[Brian Birtles (:birtles)]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #4)
> In the old animation inspector we can see warnings if the animation can not
> be run on the compositor, but now we can no longer see it?

You need to click each animation in turn to expand the keyframes. If it couldn't be run on the compositor then even after the animation is finished the property name should still have the dotted underline.

Comment 6

[Brian Birtles (:birtles)]

As best I can tell, it's the tiny little bar at the top (.nuxt-progress) where we are transitioning the 'width' property.

Although this could be done with a `transform` animation, the author may have decided that the element is so small it doesn't matter if janks.

Even so, if I delete that though we can't do the profile photo animation on the compositor because it is backface-visibility: hidden (bug 1186204).

I suspect that even after fixing that there might be further complications because of the border-radius animation but for the mean time I suspect there are two things we can do here:

* Tweak the synchronize geometric animations optimization further somehow -- I don't have any particularly good ideas for this yet
* Fix bug 1186204

Comment 7

[Hiroyuki Ikezoe (:hiro)]

Ok, thanks I found the transform animations in question.  So the properties blocks the transform animations is border-radius properties?  I can see a width transition but it...  Oh now I understand, the width transition actually blocks the transform animations but the width transition has a positive delay.  That's unfortunate.

I think, as for this particular case, we could maybe avoid the synchronization until the delayed geometric property animations get in effect state.  But we also need to tweak the transform animation's end value on the compositor to the value at the time when the width transition starts to avoid glitches when it gets synchronized.  So yeah it's tricky. :/

Comment 8

[Hiroyuki Ikezoe (:hiro)]

(In reply to Brian Birtles (:birtles) from comment #6)
> I suspect that even after fixing that there might be further complications
> because of the border-radius animation

border-radius shouldn't involve geometric changes, it only generates repaint frame change hint.

Comment 9

[Brian Birtles (:birtles)]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #7)
> I think, as for this particular case, we could maybe avoid the
> synchronization until the delayed geometric property animations get in
> effect state.  But we also need to tweak the transform animation's end value
> on the compositor to the value at the time when the width transition starts
> to avoid glitches when it gets synchronized.  So yeah it's tricky. :/

I think synchronizing based on start time (ignoring delay) is generally the correct behavior so I'm a little reluctant to change that but I don't have any better ideas.

(In reply to Hiroyuki Ikezoe (:hiro) from comment #8)
> (In reply to Brian Birtles (:birtles) from comment #6)
> > I suspect that even after fixing that there might be further complications
> > because of the border-radius animation
> 
> border-radius shouldn't involve geometric changes, it only generates repaint
> frame change hint.

Right, but it means we'll be repainting the layer each frame so I imagine we're still not going to hit the ideal path of simply re-compositing a pre-rendered layer each frame. I suppose that will matter less on WebRender though.