Sin embargo, también lo probé en un iPhone X, que es súper fluido y rápido, así que creo que la CPU será el problema. ¿Hay alguna posibilidad de mejorar el rendimiento en dispositivos más antiguos?
Pronto lo probaré; sospecho que los dispositivos más antiguos aún podrían necesitar la optimización de rendimiento (un poco rudimentaria) que reduce el número de elementos en el menú a 20 para que funcione sin problemas. Lo investigaré en breve.
@Don - solo estoy investigando más para saber qué probar, ¿estás notando esto al abrir/cerrar menús con un toque (dentro y fuera del menú), o al deslizar (manteniendo y haciendo un gesto de deslizamiento)?
El menú parece fluido cuando lo abro por primera vez. Creo que es porque los elementos del panel no se han cargado. Cuando lo abro por primera vez, aparece el indicador de carga giratorio en la parte superior. Creo que este es un buen comportamiento y tal vez sería genial usar siempre el indicador de carga giratorio al abrir.
Las aperturas después de esto son sin animaciones. El cierre es aleatorio (a veces fluido, a veces con retrasos).
Cuando se abría y hacía clic fuera, normalmente los botones del menú del panel se retrasaban. Pero esos se deslizan primero ¿Quizás esto sucede porque todo el panel del menú está en reverse-row y cuando se cierra, la clase se elimina antes de que se deslice por completo y vuelva a row?
Editar: Esos no son los botones del menú (pestaña), son solo los iconos antes de las notificaciones. Pero normalmente aparece un retraso en esa línea.
Cuando uso un gesto para cerrar el menú, parece fluido.
Por lo que puedo ver, la “lentitud” aquí se debe a que las cabeceras se vuelven a renderizar, no a las animaciones en sí.
Una cosa que introduje y que puede dar la percepción de lentitud es la animación de deslizamiento (esta animación se eliminó inadvertidamente cuando refactorizamos nuestra nueva cabecera).
Dar un poco de margen con setTimeout entre la animación y el trabajo de renderizado que hacen los menús de los widgets parece hacer que las cosas vayan mucho más fluidas, por lo que no es la animación en sí lo que es lento, así que sospecho que es el trabajo que ocurre alrededor del renderizado de las cabeceras del sitio al abrir/cerrar.
De hecho, me pregunto si el manejo de la promesa de fin de animación de Firefox se dispara después de que la animación se ha pintado por completo (asumí que este era el caso al codificar el cambio original), lo que podría explicar por qué se ve más fluido que Chrome, mientras que Chrome permite que el trabajo de recálculo comience después de que se completan los cálculos de la animación, pero antes de que se pinte el fin de la animación.
