Cependant, je l’ai testé aussi sur iPhone X, qui est super fluide et rapide, donc je pense que le CPU est le problème. Y a-t-il une possibilité d’améliorer les performances sur les anciens appareils ?
Je vais tester cela bientôt ; je soupçonne que les anciens appareils auront toujours besoin de l’optimisation des performances (un peu bricolée) qui réduit le nombre d’éléments dans le menu à 20 pour qu’ils fonctionnent sans problème - Je vais examiner cela sous peu.
@Don - juste pour approfondir ce que nous devons tester, remarquez-vous cela lors de l’ouverture/fermeture de menus avec un tap (sur le menu + hors du menu), ou avec un balayage (en maintenant et en effectuant un geste de balayage) ?
Le menu semble fluide lorsque je l’ouvre pour la première fois. Je pense que c’est parce que les éléments du panneau ne sont pas chargés. Lorsque j’ouvre pour la première fois, le chargeur spinner apparaît en haut. Je pense que c’est un bon comportement et qu’il serait peut-être intéressant d’utiliser toujours le chargeur spinner à l’ouverture.
Les ouvertures après cela se font sans animations. La fermeture est aléatoire (parfois fluide, parfois saccadée).
Lorsqu’il était ouvert et que je cliquais à l’extérieur, les boutons du menu du panneau présentaient généralement un décalage. Mais ceux-ci glissent d’abord Peut-être que cela se produit parce que tout le panneau du menu est en reverse-row et que lorsqu’il se ferme, la classe est supprimée avant qu’il ne glisse complètement et ne revienne à row ?
Modification : Ce ne sont pas les boutons du menu (onglet) mais juste les icônes avant les notifications. Mais un décalage apparaît généralement sur cette ligne.
Lorsque j’utilise un geste pour fermer le menu, cela semble fluide.
Mise à jour : Il semble que dans le navigateur Firefox, le déplacement du menu soit fluide. Je l’ai également testé sur Edge où c’est pareil qu’avec Chrome.
D’après ce que je peux dire, le « ralentissement » ici est dû au re-rendu des en-têtes, et non aux animations elles-mêmes.
Une chose que j’ai introduite et qui peut donner l’impression d’une nouvelle lenteur est l’animation de glissement (cette animation a été involontairement supprimée lorsque nous avons refactorisé notre nouvel en-tête)
Donner un peu de temps au setTimeout entre l’animation et le travail de re-rendu que font les menus des widgets semble rendre les choses beaucoup plus fluides, donc ce n’est pas l’animation elle-même qui est lente, donc je soupçonne que c’est le travail qui se déroule autour du re-rendu des en-têtes du site à l’ouverture/fermeture.
Je me demande en fait si la gestion par Firefox de la promesse de fin d’animation se déclenche après que l’animation a été bien et vraiment peinte (j’avais supposé que c’était le cas lors de la codification du changement original), ce qui pourrait expliquer pourquoi elle semble plus fluide que Chrome, alors que Chrome permet au travail de recalcul de commencer après que les calculs de l’animation sont terminés, mais avant que la fin de l’animation ne soit peinte.
