flüssige Animationen mit dem requestAnimationFrame

[jspit]

Hi,
ruckelfreie Animationen mit setInterval und setTimeout zu erstellen wird schwer, wenn mehrere Animationen gleichzeitig laufen.
Hier Performantere JavaScript-Animationen mit requestAnimationFrame werden die Vorteile des requestAnimationFrame kurz vorgestellt.
Ich habe ein wenig experimentiert und möchte ein kleines Beispiel vorstellen:

(function(id,start_width,stop_width,step){
  (function callback(){
    document.getElementById(id).style.width = (start_width) + "px"; 
    start_width += step; 
    if(start_width < stop_width) window.requestAnimationFrame(callback);
    })();
})('test',60,300,1);

Das ganze ist eine anonyme Funktion, welche ein Element mit der id 'test' (1.Parameter) mit einer Startbreite von 60 px (2.Parameter) bis zu einer Breite von 300 (3.Parameter) animiert. Der 4 Parameter ist die Schrittweite.

Das kleine Beispiel für andere Animationen zu modifizieren sollte nicht schwer sein.

Mit dem Onlinetest kann ein wenig mit den Parametern experimentiert werden. Ebenso kann so schnell ermittelt werden, mit welchen Browsern dies gut läuft.

LG jspit

 

[kkapsner]

Da auch requestAnimationFrame mal etwas hängen kann, sollte man auch hier seine Schrittweite nicht fest pro Funktionsaufruf, sondern fest pro Zeiteinheit wählen.

PS: arguments.callee ist deprecated. Gib' deiner inneren Funktion doch einen Namen, dann kannst du den für das requestAnimationFrame() verwenden.
PPS: ich verwende für Animationen das:

var requestAnimationFrame =
	window.requestAnimationFrame ||
	window.mozRequestAnimationFrame ||
	window.webkitRequestAnimationFrame ||
	window.oRequestAnimationFrame ||
	window.khtmlRequestAnimationFrame ||
	window.msRequestAnimationFrame ||
	function(callback){
		return window.setTimeout(callback, 50);
	};

 

[jspit]

Die Framerate vom requestAnimationFrame kann nicht hängen wie beim setTimeout, kann aber runtergesetzt werden wenn notwendig. Da besteht ein feiner Unterschied. Die Framerate wird so gewählt (Erfahrungswert bei 16ms), das die Rate mit dem Rendern des Bildschirminhaltes gewissermaßen synchronisiert wird. Dadurch wird eine flüssige Darstellung erreicht. Das bedeutet jedoch nicht, das die Animation immer mit gleicher Geschwindigkeit erfolgt.
Für das obige Beispiel bedeutet das, der Balken kann auch mal langsamer wachsen.
Dies durch eine Schrittweitenanpassung zu kompensieren, nicht anderes meint kkapsner, ist nicht ganz so einfach wie es auf den ersten Blick erscheint.
Denn der requestAnimationFrame pausiert bei Verlassen des Browsertabs mit seiner Animation um Gegensatz zum setTimeout, welcher weiterläuft.
Das zu Berücksichtigen bedeutet entsprechende Events zu erstellen, welche in die Schrittweitenanpassung eingreifen.

Das mit arguments.callee hab ich mal geändert, sieht so auch optisch besser aus.

LG jspit

 

[tsseh]

Das bedeutet jedoch nicht, das die Animation immer mit gleicher Geschwindigkeit erfolgt.

die animation sollte nicht von dem willkürlichen aufrufzeitpunkt des callbacks abhängig sein, weder bei setTimeout noch bei requestAnimationFrame. bei beiden ist ein zeitpunkt nicht definiert.

Für das obige Beispiel bedeutet das, der Balken kann auch mal langsamer wachsen.

wenn das nicht beabsichtigt ist, sollte man das beheben

Das zu Berücksichtigen bedeutet entsprechende Events zu erstellen, welche in die Schrittweitenanpassung eingreifen.

nein ganz und gar nicht, wenn du den Tab wieder wechselst, wird gerendert, also auch dein callback aufgerufen.
du siehst also genau das abbild der animation welches du sehen sollst.

also, wenn du z.B. hier http://forum.jswelt.de/javascript/58527-js-neuling-performance-frage-animation.html#post373003 während der animation den tab wechselst und nach einer stunde wieder zurück wechselst, siehst du genau das, was du sehen sollst, den endzustand der animation.

 

[kkapsner]

Die Framerate vom requestAnimationFrame kann nicht hängen wie beim setTimeout

Da wiederspricht dir leider die Praxis - hier: http://forum.jswelt.de/javascript/58972-progressives-ausf-llen-vektorgrafiken.html hab' ich das gemessen und schon verschiedene Werte bekommen...

Aber über ein Date-Objekt kann man die Animationsgeschwindigkeit recht einfach kontrollieren.

 

[tsseh]

Da wiederspricht dir leider die Praxis - hier: http://forum.jswelt.de/javascript/58972-progressives-ausf-llen-vektorgrafiken.html hab' ich das gemessen und schon verschiedene Werte bekommen

hat er ja auch nicht behauptet:

Die Framerate vom requestAnimationFrame kann nicht hängen wie beim setTimeout, kann aber runtergesetzt werden wenn notwendig.

die framerate bei requestAnimationFrame wird vollkommen vom browser bestimmt und ist dabei an dessen rendering gekoppelt. über das zeitverhalten kann man vorab überhaupt nichts aussagen - nochweniger als bei setTimeout.

 

[jspit]

die framerate bei requestAnimationFrame wird vollkommen vom browser bestimmt und ist dabei an dessen rendering gekoppelt. über das zeitverhalten kann man vorab überhaupt nichts aussagen - nochweniger als bei setTimeout.

Hab dazu mal einige eigene Messungen (mit performance.now(); ) gemacht, das Ergebnis war für mich erschreckend.
Bekam solche Folgen (in ms): 16 16 7 16 16 16 16 7 16 ...
Und das ohne 'Belastung'. Es st schon wichtig, hier auch eine Zeitmessung mitlaufen zu lassen, wenn eine kontinuierliche Animation angestrebt werden soll.
Meine Hoffnung aus der Theorie war eine andere Und das Date-Objekt ist dafür sicher ausreichend.

 

[tsseh]

Hab dazu mal einige eigene Messungen (mit performance.now(); ) gemacht, das Ergebnis war für mich erschreckend.

Was ist daran erschreckend? die framerate ist doch sehr gut!

Meine Hoffnung aus der Theorie war eine andere Und das Date-Objekt ist dafür sicher ausreichend.

dass die framerate dabei nicht fest ist, sondern variabel soll ja gerade der vorteil sein. also das callback wird immer dann gerufen, wenn sowieso gerendert werden muss oder wenn dass lange zeit nicht passieren würde, wird ein aufruf dazwischengeschoben.
und selbst über Timeout/intervall verlässt man sich nicht auf die vorgegebenen angaben, sondern bestimmt die zeiten im callback, weil diese nicht stimmen müssen.

 

[kkapsner]

Genau das hatte ich mit meiner Aussage gemeint: du kannst dich nicht darauf verlassen, dass die Funktion immer nach einer bestimmten Zeit ausgeführt wird (was für mich ein "hängen" ist) und du mit einem Date-Objekt dir die verstrichene Zeit ausgeben lassen must.

@jspit: bei mir waren die Unterschiede noch stärker, da mein System unter Last stand.