New mobile menu panel moving slow and laggy on older devices

Hello :wave:

Since the UX: improve touch, swipe, panning performance on mobile menus by featheredtoast 路 Pull Request #23775 路 discourse/discourse 路 GitHub update the menu panel (user and sidebar) moving feels much slower than before on older mobile Android devices. It maybe because these devices CPU performance is not enough to make it moves smooth.

On my device Huawei P20 Pro.

However I tested it on iPhone X too which is super smooth and fast so I think the CPU will be the problem. Is that any chance to improve performance on older devices?

Thank you :slightly_smiling_face:

6 Likes

Thanks @Don we will have a look!

2 Likes

Hey Don, thanks for the feedback!

I鈥檒l have this tested soon; my suspicion is that older devices may still need the (slightly hacky) perf optimization reducing the number of items in the menu to 20 to feel smooth - Will look into this shortly.

3 Likes

@Don - just further digging in to know what to test for, are you noticing this for opening/closing menus with a tap (on menu + off menu), or swiping (holding and gesturing swipe)?

2 Likes

The menu seems smooth when I firstly opens it. I think because the panel elements not loaded. When I firstly open the spinner loader appears on top. I think this is a good behavior and maybe going to be cool to use always the spinner loader on openings. :thinking:

The openings after this is without animations. The closing is random (sometimes smooth sometimes laggy)

When it opened and I click outside usually the panel menu buttons lagging. But those slide out first :thinking: Maybe this is happens because the whole menu panel is in reverse-row and when it closes the class removes before it fully slide out and change back to row?

Edit: That is not the menu panel buttons (tab) that鈥檚 just the icons before notifications. But it鈥檚 usually lagg appear on that line.

When I use gesture to close menu it seems smooth.

2 Likes

Update: It seems in Firefox browser the menu moving is smooth. I tested it also on Edge where same as Chrome.

Firefox

From what I can tell, the 鈥渓agginess鈥 here is due to headers re-rendering, not the animations themselves.

One thing I did introduce that may give the perception of new-slowness is the slide-out animation (this animation was inadvertently removed when we refactored our new header)

Giving some setTimeout breathing room between animation and the rerender work the widget menus are doing seem to make things go a lot smoother, so it鈥檚 not the animation itself that鈥檚 slow, so my suspicion is it鈥檚 the work going on around rerendering the site headers on open/close.

I鈥檓 actually wondering if firefox鈥檚 handling of animation end promise is firing after the animation is well and truly painted (I had assumed this to be the case when coding the original change), which might explain why it looks smoother than chrome, whereas chrome allows recalculation work to start after the animation鈥檚 calculations are done, but before the animation end is painted.


EDIT: I鈥檓 adding a pause using our runloop to add the necessary breathing space before animating, this should make the animation feel much smoother: PERF: only add and remove class lists on testing by featheredtoast 路 Pull Request #24168 路 discourse/discourse 路 GitHub

3 Likes

Whooo thanks so much! Nice catch! :heart_eyes:

2 Likes