Wenn ich eine Schleife mit requestAnimationFrame wie folgt habe:
%Vor% Wird es einen Unterschied geben, wenn ich das requestAnimationFrame am Anfang der Funktion setze, wie folgt:
Ich habe keinen Unterschied bemerkt, aber ich habe beide Implementierungen gesehen, ist einer von ihnen in irgendeiner Weise besser oder sind sie gleich?
Bearbeiten: Eine Sache, über die ich nachgedacht habe, ist, wenn ich es am Anfang schreibe, und der Render-Code recht lange braucht, sagen wir 10ms, würdest du ihn am Ende nicht mit 10ms fallen lassen?
requestAnimationFrame ruft seinen Callback immer asynchron auf. Solange der Rendering-Code synchron ist und keine Ausnahmen auslöst, macht das keinen Unterschied.
Es ist im Wesentlichen eine Stilwahl, wählen Sie selbst, welcher Ansatz sauberer ist. Wenn Sie es oben platzieren, können Sie betonen, dass render sich selbst plant, und zwar auch bei Fehlern im Rendering. Wenn Sie es in den Boden legen, können Sie bedingt aus der Rendering-Schleife ausbrechen (z. B. wenn Sie Ihr Spiel pausieren möchten).
Es wird wahrscheinlich keinen Unterschied machen. Die requestAnimationFrame -Methode ist asynchron, Ihre Renderfunktion wird also wie erwartet funktionieren. Aber ... es gibt einen Haken wenn es darum geht anzuhalten. Angenommen, Sie haben den folgenden Code:
Um den nächsten Rendervorgang zu stoppen, ist ein Aufruf der Methode cancelAnimationFrame erforderlich, etwa so:
Andernfalls wird die Methode render einfach unbegrenzt ausgeführt. Alternativ könnten Sie Folgendes tun:
Wie bei frame dropping könnten Sie requestAnimationFrame als einen festen Zeitplan betrachten (bei 60 Frames pro Sekunde wären es ungefähr 16ms Intervalle). Wenn Ihr Code länger dauert, wird der Browser Frames löschen. Sehen Sie sich Patrick Roberts Antwort an, um Anweisungen zu erhalten, wie Sie Ihre Bilder in die Hand nehmen und diese für ein konsistenteres Rendering verwenden können. p>
Ich hoffe, das hilft!
Um Ihre Frage zu beantworten, werden diese beiden Funktionen einen Unterschied in der Zeitspanne machen, die der asynchrone Callback nur benötigt, wenn Ihr Rendering-Code länger ist als die Animations-Frame-Geschwindigkeit (typischerweise 16 - 33ms, abhängig von der Browser-Implementierung). Wenn Sie diese API jedoch wie vorgesehen verwenden, sollte dies auch keinen Unterschied machen.
Beachten Sie, dass Sie den optionalen Parameter aus requestAnimationFrame timestamp .
Stellen Sie sicher, dass Sie Ihre Deltas berechnen, wenn Sie Delta-abhängige Animationen zum Rendern haben. In der Regel multipliziert man eine Animation "Geschwindigkeit" mit dem timestamp delta (aktuelle timestamp minus vorherige timestamp ), um eine effektive Distanz zu erhalten, die ein Objekt über den Bildschirm zurücklegen sollte. Der Effekt ist besonders bemerkbar, wenn der Rendering-Code nicht konsistent die gleiche Zeit benötigt, um jeden Frame auszuführen.
Beachten Sie, dass das blaue Quadrat insgesamt eine gleichmäßigere Geschwindigkeit aufweist. Das ist die Absicht.
In der MDN-Beschreibung heißt es:
Die Methode window.requestAnimationFrame () teilt dem Browser mit, dass Sie eine Animation ausführen möchten, und fordert den Browser auf, eine bestimmte Funktion aufzurufen, um eine Animation vor dem nächsten Repaint zu aktualisieren.
Wenn das Repaint auftritt, ist dies weitgehend der Browser. Es sollte keinen Unterschied in Verhalten geben, wenn Ihr JS noch ausgeführt wird, wenn das Repaint aufgetreten wäre.
In der WhatWG-Spezifikation wird nicht darauf hingewiesen, dass der JS-Aufrufstapel gelöscht oder gelöscht werden muss alles von der Art, obwohl eine außergewöhnlich lange laufende Funktion den UI-Thread blockiert und daher verhindern sollte, dass Animationsframes aufgerufen werden.
Tags und Links javascript requestanimationframe