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?
I’ll 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.
@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)?
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.
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 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’s just the icons before notifications. But it’s usually lagg appear on that line.
From what I can tell, the “lagginess” 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’s not the animation itself that’s slow, so my suspicion is it’s the work going on around rerendering the site headers on open/close.
I’m actually wondering if firefox’s 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’s calculations are done, but before the animation end is painted.
