was meinst du denn mit Bildschirmbildaufbau? den inhalt des grafikspeichers auf den monitor projizieren?
Ja. Das was ich zu sehen bekomme.
damit hat der browser gar nichts zu tun. [...]
Mir ist schon klar, dass sich der Browser nicht selbst um den Monitor kümmert. Aber wenn der Grafikspeicher nur alle 20ms "projiziert" wird, ist es nicht sinnvoll einen Vorgang, der sehr aufwändig ist und nur dort zu sehen ist, öfters durchzuführen.
damit können wir eigentlich hier aufhören, ich sehe hier keine großartigen unterschiede in den abweichungen zw. animation und setTimeout, worum es ja ursprünglich ging
Stimmt - ich hatte ehrlich gesagt mehr Streuung beim setTimeout erwartet. Aber da alles nicht genau ist, sollte man seine Animationen immer mit einem Date-Objekt (oder mit window.performance, wo verfügbar) steuern.
weil 4ms ja auch nicht nötig ist bzw. die 20ms, oder wie du selbst sagtest, die bildfrequenz des monitors sicher schon ein gutes bewegtes bild erzeugen.
laut wikipedia:
warum sollte man da öfter ändern als überhaupt dargestellt wird?
Genau das ist ja mein Punkt. Es ändert sich 5 mal das DOM, aber es wird nur ein Repaint und damit nur einmal das requestAnimationFrame ausgeführt.
so arbeitet aber keine anwendung
Das glaube ich nicht. Alles was eine flüssige Darstellung braucht wird sich auf die Grafikkarte und damit den Monitor abstimmen. Sonst bekommst du, trotz dem 50 Hz, ruckelige Bilder (wenn du z.B. etwas in den Grafikspeicher schreibst, während der gerade ausgelesen wird - das ergibt ganz fiese Effekte). Z.B. ein Grafikintensives Spiel wird das Rendern nur so häufig wie nötig machen - wobei das die Hauptarbeit natürlich auf die Grafikkarte abwälzt.
wenn ich einen test mache, mit einem button(so, dass der browser nicht intern optimieren kann und so evtl. timeouts mit animationen zusammenlegt), bekomme ich bei 1000 aufrufen ohne den button zu drücken so zw. 30 und 60 abweichungen größer 1ms vom mittelwert
wenn ich jetzt den button zwischendurch immer mal drücke, welcher ein element ins dom einfügt, werden das 200 bis 250 abweichungen
Zeig' mir bitte deinen Code. Hat sich bei der Messung der Mittelwert verschoben? Bitte Zahlen.
Wenn ich sowas einbaue (und dazu auch noch das window.setTimeout() unverhersehbar mache):
Code:
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title>Fenstertitel</title>
<script type="text/javascript" src="/kkjs/modules/kkjs.load.js?modules=Timer,sprintf"></script>
</head>
<body>
Running...
<div id="timer"></div>
<div id="animationResult"></div>
<div id="normalResult"></div>
<button id="userButton">click (<span id="clickCount">0</span>)</button>
<script type="text/javascript">
function generateTimer(output){
var t = new kkjs.Timer(10000);
var lastNow = Date.now();
var sum = 0;
var count = 0;
var sum2 = 0;
t.on("tick", function(){
var now = Date.now();
var diff = now - lastNow;
sum += diff;
count += 1;
sum2 += diff * diff
lastNow = now;
});
t.on("timeOver", function(){
t.stop();
output.innerHTML = kkjs.sprintf(
"mean: %f ± %f",
sum / count,
Math.sqrt(sum2/count - sum*sum/count/count)
);
});
return t;
}
var t = generateTimer(kkjs.$("animationResult"));
t.animation = true;
var t2 = generateTimer(kkjs.$("normalResult"));
t2.tickTime = 0;
t2.on("tick", function(){
this.tickTime = Math.random() * 50;
kkjs.$("timer").innerHTML = this.getTimeString() + " (" + Math.random() + ")";
});
t2.start();
t.start();
count = 0;
kkjs.event.add(kkjs.$("userButton"), "click", function(){
count += 1;
kkjs.$("clickCount").innerHTML = count;
});
</script>
</body>
</html>
bekomme ich auch so gut wie das Gleiche (außer beim FF - aber der hat bei mir auch das schlechteste Renderverhalten):
Code:
Chrome:
mean: 19.922310756972113 ± 1.2368593110062804
mean: 24.330900243309003 ± 14.117080607653715
click (81)
Firefox:
mean: 20.34349593495935 ± 5.2759134351490955
mean: 26.497354497354497 ± 15.307820160972655
click (101)
IE:
mean: 20.024 ± 1.2631009460846667
mean: 31 ± 17.709209442298867
click (103)
Opera:
mean: 19.88667992047714 ± 1.4202040815092656
mean: 25.648717948717948 ± 14.314138103231917
click (101)
- das setTimeout streut jetzt natürlich viel mehr, da es auf zufällige Werte zwischen 0 und 50ms gestellt wurde - vor jedem Tick.
Da kann der Browser jetzt gar nichts optimieren, da er nichts weiß.
Ich denke mal, dass bei deinem Test das Erzeugen des DOM-Elements das ganze unter Last legt - und JS-Timing mit Last ist nie präzise. Bei mir wird nur der Text des <button>s geändert - aber auch das muss neu gezeichnet werden.
