1512768 - Pottermore hamburger menu slide-in animation is janky

Status: RESOLVED FIXED

(Core :: Layout, defect, P3)

Description

[Daniel Holbert [:dholbert]]

STR:
1. Visit https://www.pottermore.com in Firefox on Android
2. Tap the site's hamburger menu in top left

ACTUAL RESULTS:
Slide in animation is janky

EXPECTED RESULTS:
smooth animation


Chrome gives expected results.

Not sure where this bug belongs; starting in generic layout.

Comment 1

[Hiroyuki Ikezoe (:hiro)]

The jank happens when the menu is being closed, right?  The janky animation is due to the restriction that transform animations starts with geometric animations.

Brian, I think it would be nice to have one WONTFIX bug (bug 1495653?) and mark the others as duplicate of it?

Another thing I have in mind is that we should provide suggestions or show a link to a document (on MDN I assume) which explains this restrictions and how web developers can avoid the restrictions in the animation inspector?   And I am pretty sure we should make it more noticeable than the lightning volt because the situation where the things are not going well is more important than the things are working well for web developers.

Comment 2

[Daniel Holbert [:dholbert]]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #1)
> The jank happens when the menu is being closed, right?

No, it's when it opens. I see distinct jumps as it opens (in Firefox), like it's a rapid slide show. And it feels much smoother in Chrome on the same device (Pixel 2, Android P)

Comment 3

[Hiroyuki Ikezoe (:hiro)]

Thank you, Daniel.  I did check the site on a Mobile phone, opening the menu animation actually looks janky on the phone.  And the CSS property of the janky animation is 'left' which from '-100%' to '0px'.  It seems to me that the issue here is more general in layout area.  Moving back to layout component.  We need to take a profile.

Comment 4

[Daniel Holbert [:dholbert]]

Here are 2 profiles of the "menu open" action, taken in Nightly:
  https://perfht.ml/2UFykSt
  https://perfht.ml/2UyvXRD

Looks like we've got some very slow paints there (in the 60ms-120ms range) during the animation.

Comment 5

[Daniel Holbert [:dholbert]]

Looks like all of the time is spent in nsLayoutUtils::DrawBackgroundImage.

I'm guessing that's for the page's background photos (which are "behind" the opening menu here). If that's the case: I wonder why we're redrawing the photo rather than just recompositing on top of it?

FWIW: it looks like the menu itself (the element with class="header__pane--navigation") is abspos and is brought on-screen by transitioning from "left: 100%" to "left: 0" (by adding class=-is_open").

Comment 6

[Daniel Holbert [:dholbert]]

Setting needinfo=me to test this in webrender with geckoview example app when I get a chance. If this is fixed by webrender (as mstange suspects), that'll help us understand & reason about prioritization.

Comment 7

[Markus Stange [:mstange]]

See https://wiki.mozilla.org/Platform/GFX/Quantum_Render#Android for how to test WebRender on Android

Comment 8

[Daniel Holbert [:dholbert]]

Yeah, webrender seems to make this jank go away. (The final few frames of the animation are still slightly janky, but they are in Chrome for Android as well.)

I downloaded geckoview_example.apk from a recent mozilla-central run:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=217742247&repo=mozilla-central&lineNumber=39353
https://queue.taskcluster.net/v1/task/MEPP8SCZRpqNCzE9D7NsAQ/runs/0/artifacts/public/build/geckoview_example.apk
...and verified that the menu slide-in was janky. Then I toggled gfx.webrender.all to true, restarted, and tried again, and it was pretty smooth.

mstange, what do you think that means from a [qf] perspective? We can circle back to this at next triage, too.

Comment 9

[Daniel Holbert [:dholbert]]

For reference, here's a screencast of what this bug's jank looks like on my Pixel 3 in geckoview_example:
https://www.youtube.com/watch?v=K9317K02NSo

...and here it is with webrender enabled (better)
https://www.youtube.com/watch?v=5540j9Kzm0o

Comment 10

[Jean Gong :jgong]

Miko, please take a look at this bug as per the QF triage team.

Comment 11

[Daniel Holbert [:dholbert]]

FWIW, the slide-in here is from a CSS Transition of the "left" CSS property, from adding the "is-open" CSS class:

.header--wizarding-world .header__pane.is-open {
    left: 0;
    width: 100%;
}

The width remains constant (there's another rule that also makes it width:100%), so we're just animating the position of this absolutely positioned element.

I don't recall if that's a known-slow scenario (i.e. if we'd expect to have to repaint or just recomposite during such an animation) -- hiro, do you recall?

Comment 12

[Markus Stange [:mstange]]

The individual text items in the sidebar have transform + opacity animations, but those don't seem to be handled using OMTA here. Probably because there's a "left" animation going on at the same time?

Comment 13

[Daniel Holbert [:dholbert]]

There is indeed a "left" transition going on at the same time, yeah (for the whole menu itself sliding in).

Comment 14

[Hiroyuki Ikezoe (:hiro)]

(In reply to Markus Stange [:mstange] from comment #12)

The individual text items in the sidebar have transform + opacity
animations, but those don't seem to be handled using OMTA here. Probably
because there's a "left" animation going on at the same time?

Yes, that's right. We don't run transform transitions on the compositor if there is other geometric transitions started at the same time. This restriction was introduced in bug 1301305 to avoid gaps between transforms and geometric changes.

Also I heard that Chrome will do the same restriction.

Comment 15

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

Yeah, we need to tweak that heuristic. We already tweaked it once for the iPhone homepage (bug 1502026) but there are other bugs where it's giving us suboptimal results like bug 1506932.

Comment 16

[Miko Mynttinen]

(In reply to Jean Gong :jgong (OOO Dec 20 - Jan 8) from comment #10)

Miko, please take a look at this bug as per the QF triage team.

I think there are other people better suited for investigating this bug further.

Comment 17

[Hiroyuki Ikezoe (:hiro)]

Removing bug 1540906 dependency since now the Pottermore site doesn't use transform transition on the hamburger menu. It's max-width and top transitions. It still looks slower than Chrome though.