Ich habe es jedoch auch auf einem iPhone X getestet, was super flüssig und schnell ist, daher denke ich, dass die CPU das Problem sein wird. Gibt es eine Möglichkeit, die Leistung auf älteren Geräten zu verbessern?
Ich werde das bald testen lassen. Ich vermute, dass ältere Geräte möglicherweise immer noch die (etwas umständliche) Leistungsoptimierung benötigen, die die Anzahl der Menüpunkte auf 20 reduziert, um reibungslos zu funktionieren – ich werde mich bald darum kümmern.
@Don – nur um weiter zu untersuchen, was getestet werden muss: bemerkst du dies beim Öffnen/Schließen von Menüs durch Tippen (auf Menü + außerhalb von Menü) oder durch Wischen (Halten und Wischgeste)?
Das Menü scheint beim ersten Öffnen reibungslos zu funktionieren. Ich glaube, das liegt daran, dass die Panel-Elemente noch nicht geladen sind. Wenn ich es zum ersten Mal öffne, erscheint oben ein Spinner-Loader. Ich denke, das ist ein gutes Verhalten und vielleicht wäre es cool, den Spinner-Loader immer beim Öffnen zu verwenden.
Die anschließenden Öffnungen erfolgen ohne Animationen. Das Schließen ist zufällig (manchmal reibungslos, manchmal verzögert).
Wenn es sich öffnet und ich außerhalb klicke, hinken die Menü-Buttons des Panels normalerweise. Aber diese gleiten zuerst heraus Vielleicht passiert das, weil das gesamte Menü-Panel in reverse-row ist und beim Schließen die Klasse entfernt wird, bevor es vollständig herausgleitet und zurück zu row wechselt?
Bearbeitung: Das sind nicht die Buttons (Tabs) des Menü-Panels, sondern nur die Icons vor den Benachrichtigungen. Aber auf dieser Zeile tritt normalerweise eine Verzögerung auf.
Wenn ich eine Geste zum Schließen des Menüs verwende, scheint es reibungslos zu funktionieren.
Update: Es scheint, dass im Firefox-Browser die Menübewegung reibungslos verläuft. Ich habe es auch unter Edge getestet, wo es dasselbe wie unter Chrome ist.
Soweit ich das beurteilen kann, liegt die “Langsamkeit” hier am Neurendern der Header und nicht an den Animationen selbst.
Eine Sache, die ich eingeführt habe und die den Eindruck von neuer Langsamkeit erwecken könnte, ist die Slide-out-Animation (diese Animation wurde versehentlich entfernt, als wir unseren neuen Header refaktoriert haben).
Wenn man dem setTimeout etwas Luft zwischen der Animation und der Neurender-Arbeit, die die Widget-Menüs ausführen, gibt, scheint es viel reibungsloser zu laufen, sodass nicht die Animation selbst langsam ist. Mein Verdacht ist daher, dass die Arbeit rund um das Neurendern der Website-Header beim Öffnen/Schließen schuld ist.
Ich frage mich tatsächlich, ob Firefows Umgang mit dem Animationsende-Promise nach dem tatsächlichen Malen der Animation ausgelöst wird (ich ging davon aus, dass dies der Fall ist, als ich die ursprüngliche Änderung kodierte), was erklären könnte, warum es reibungsloser aussieht als Chrome, während Chrome die Neuberechnungsarbeit beginnen lässt, nachdem die Berechnungen der Animation abgeschlossen sind, aber bevor das Animationsende gemalt wird.
