Seite 2 von 2 ErsteErste 12
Ergebnis 16 bis 28 von 28
  1. #16
    Avatar von kkapsner
    kkapsner ist offline Super Moderator
    registriert
    28-03-2008
    Beiträge
    17.760

    AW: Javascript: Funktion in Objekt übergeben und als Property speichern.

    Zitat Zitat von hesst Beitrag anzeigen
    der grüne ist wohl weg?
    - anscheinend... @mo: kannst du den wieder reinbringen?

    Zitat Zitat von hesst Beitrag anzeigen
    und browserunterschiede?
    Hier mein kleiner Test:
    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.kkapsner.de/modules/kkjs.load.js?modules=Timer"></script>
    <style type="text/css"></style>
    </head>
    <body>Running...
    <script type="text/javascript">
    var t = new kkjs.Timer(10000);
    t.animation = true;
    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.start();
    
    t.on("timeOver", function(){
    	t.stop();
    	document.body.innerHTML = kkjs.sprintf(
    		"mean: %f &plusmn; %f",
    		sum / count,
    		Math.sqrt(sum2/count - sum*sum/count/count)
    	);
    });
    </script>
    </body>
    </html>
    und meine Ergebnisse (Rechner dabei komplett ohne Last - auch keine Mausbewegungen):
    Firefox 29: mean: 20 ± 0.8717797887081294
    Chrome 34: mean: 19.92430278884462 ± 1.0070701320903352
    Opera 20: mean: 19.882703777335983 ± 1.362724089484473
    IE 11: mean: 20.008 ± 1.4085226302761242
    Safari kann ich nicht testen.
    Ich finde das recht gut. Wenn man den Rechner jetzt belastet oder in der Callbackfunktion jetzt was Rechenintensives macht kann die Stabilität natürlich leiden.

    Zitat Zitat von hesst Beitrag anzeigen
    weil ich den browser z.b. durch js zum rendern veranlassen kann. wann gerendert wird ist nicht vorhersehbar.
    Ja aber darum geht es bei window.requestAnimationFrame() doch auch gar nicht. Das ruft die Funktion ja nicht dann auf, wenn irgendwas anderes ein Rendern der Seite nötig macht - das könnte ja theoretisch ewig dauern. Sondern es sagt: ruf meine Funktion vor dem nächsten möglichen Rendern auf. So hab' ich das jedenfalls verstanden und meine Tests zeigen das auch.

    Zitat Zitat von hesst Beitrag anzeigen
    animationen sind ans rendern gekoppelt, und das passiert, wenn sich was am dom ändert.
    ...und das Rendern an den Monitor. Und Rendern passiert nicht immer, wenn sich was im DOM ändert und kann auch bei anderen Sachen (z.B. Scrollen) ausgelöst werden. Aber, wie schon gesagt, sollte das irrelevant sein, da es nur um den möglichen Renderzeitpunkt geht.

  2. #17
    tsseh ist offline Foren-Gott
    registriert
    19-05-2008
    Beiträge
    5.667
    Zitat Zitat von kkapsner Beitrag anzeigen
    Ja aber darum geht es bei window.requestAnimationFrame() doch auch gar nicht.
    was heisst, darum geht es nicht? nein, bzw. doch.
    requestAnimationFrame ist die antwort auf das problem.
    angenommen du hast viele animationen.
    animation 1 berechnet etwas im callback und ändert was im dom => der browser muss rendern.
    dann kommt animation 2 bis n => es wird n fach gerendert.
    requestAnimationFrame sorgt jetzt dafür, das alle animationen vor einem sowieso benötigten rendern gerufen werden, dort ihre berechnungen machen und das dom ändern können. => nur noch einmal rendern, wenn sowieso gerendert werden muss

    Zitat Zitat von kkapsner Beitrag anzeigen
    Das ruft die Funktion ja nicht dann auf, wenn irgendwas anderes ein Rendern der Seite nötig macht
    warum nicht? das ist doch die ideale stelle

    Zitat Zitat von kkapsner Beitrag anzeigen
    das könnte ja theoretisch ewig dauern.
    natürlich kann das sein, war nach einer gewissen zeit kein rendern nötig, wird ein aufruf der animationen zwischengeschoben

    Zitat Zitat von kkapsner Beitrag anzeigen
    Sondern es sagt: ruf meine Funktion vor dem nächsten möglichen Rendern auf.
    ja, das sage ich doch auch? und das ist doch genau das was das ganze unvorhersehbar macht. an irgendeiner stelle wird irgendwann irgendwas ins dom eingefügt. rendern erforderlich! callbacks werden gerufen.

    Zitat Zitat von kkapsner Beitrag anzeigen
    ...und das Rendern an den Monitor.
    was hat das rendern mit dem monitor zu tun? klar, man kann die zusätzlich nötigen zwischenaufrufe, wnn kein rendern nötig war, an bekannte parameter anpassen(das auge nimmt max. x bilder pro sek. war, darum ist eine framerate von y gut), aber der browser rendert nur, wenn er muss, wen es änderungen gibt.

    Zitat Zitat von kkapsner Beitrag anzeigen
    Und Rendern passiert nicht immer, wenn sich was im DOM ändert
    das wäre in bug

    Zitat Zitat von kkapsner Beitrag anzeigen
    und kann auch bei anderen Sachen (z.B. Scrollen) ausgelöst werden.
    ja auch dann muss gerendert werden

    Zitat Zitat von kkapsner Beitrag anzeigen
    Aber, wie schon gesagt, sollte das irrelevant sein, da es nur um den möglichen Renderzeitpunkt geht.
    den beeinflusst du doch aber damit. du scrollst => rendern nötig => callback rufen

  3. #18
    Avatar von kkapsner
    kkapsner ist offline Super Moderator
    registriert
    28-03-2008
    Beiträge
    17.760

    AW: Javascript: Funktion in Objekt übergeben und als Property speichern.

    Zitat Zitat von hesst Beitrag anzeigen
    was heisst, darum geht es nicht? nein, bzw. doch.
    Wenn ich eine Animation mache, will ich nicht darauf warten, dass irgendwas Anderes ein Rendern nötigt macht...
    Zitat Zitat von hesst Beitrag anzeigen
    requestAnimationFrame ist die antwort auf das problem.
    [...]
    Mit ist das Problem und die Lösung schon klar.

    Zitat Zitat von hesst Beitrag anzeigen
    warum nicht? das ist doch die ideale stelle
    Nein, ist es nicht. Die ideale Stelle ist vor dem nächsten möglichen Renderzeitpunkt.

    Zitat Zitat von hesst Beitrag anzeigen
    natürlich kann das sein, war nach einer gewissen zeit kein rendern nötig, wird ein aufruf der animationen zwischengeschoben
    Da sagen meine Tests was anderes. Da wurde requestAnimationFrame kontinuierlich alle 20ms (= 50Hz = Frequenz des Monitors) aufgerufen obwohl überhaupt gar nichts irgendwie auf dem Bildschirm gerendert werden musste in den 10 Sekunden. Wie gesagt, ich hab' noch nicht einmal die Maus bewegt.


    Zitat Zitat von hesst Beitrag anzeigen
    ja, das sage ich doch auch? und das ist doch genau das was das ganze unvorhersehbar macht. an irgendeiner stelle wird irgendwann irgendwas ins dom eingefügt. rendern erforderlich! callbacks werden gerufen.
    Nein, das sagst du nicht. Du sagst "beim nächsten nötigen Rendern" und ich sage "beim nächsten möglichen Renderzeitpunkt". Das macht einen riesen Unterschied: deines ist nicht vorherseh bar und meines schon (in gewissen Grenzen). Wenn du Tests hast, die deine Meinung belegen, sehe ich sie mir gerne an. Den Test, der meine Meinung bestätig (so jedenfalls interpretiere ich das), hab' ich dir ja schon gezeigt.

    Wenn ich dich falsch verstehe, sag's bitte.

    Zitat Zitat von hesst Beitrag anzeigen
    was hat das rendern mit dem monitor zu tun?
    Äh... ohne Monitor brauchst du gar kein Rendern, da man nichts sieht...
    Zitat Zitat von hesst Beitrag anzeigen
    klar, man kann die zusätzlich nötigen zwischenaufrufe, wnn kein rendern nötig war, an bekannte parameter anpassen(das auge nimmt max. x bilder pro sek. war, darum ist eine framerate von y gut), aber der browser rendert nur, wenn er muss, wen es änderungen gibt.
    Natürlich rendert der nur, wenn er muss. Aber requestAnimationFrame stößt ja auch kein Rendern direkt an. Nur was darin passiert, kann ein Rendern anstoßen.

    Zitat Zitat von hesst Beitrag anzeigen
    das wäre in bug
    Nö, wäre es nicht. Wenn ich im DOM ein verstecktest Element verändere muss nicht gerendert werden.


    Zitat Zitat von hesst Beitrag anzeigen
    den beeinflusst du doch aber damit. du scrollst => rendern nötig => callback rufen
    ... ich kann mich nur wiederholen... der Callback wird aufgerufen, auch wenn kein Rendern nötig ist...

    Technisches Zitat, auf das ich zusätzlich meine Meinung aufbaue:
    Zitat Zitat von https://developer.mozilla.org/en-US/docs/Web/API/window.requestAnimationFrame
    This will request that your animation function be called before the browser performs the next repaint. The number of callbacks is usually 60 times per second, but will generally match the display refresh rate in most web browsers as per W3C recommendation. The callback rate may be reduced to a lower rate when running in background tabs.

  4. #19
    tsseh ist offline Foren-Gott
    registriert
    19-05-2008
    Beiträge
    5.667

    AW: Javascript: Funktion in Objekt übergeben und als Property speichern.

    Zitat Zitat von kkapsner Beitrag anzeigen
    Wenn ich eine Animation mache, will ich nicht darauf warten, dass irgendwas Anderes ein Rendern nötigt macht...
    Nein, aber wenn schon gerendert werden muss, kann man hier prima einen aufruf machen.

    Zitat Zitat von kkapsner Beitrag anzeigen
    Nein, ist es nicht. Die ideale Stelle ist vor dem nächsten möglichen Renderzeitpunkt.
    einen möglichen renderzeitpunkt kennt der browser aber nach dem parsen nicht mehr.

    Zitat Zitat von kkapsner Beitrag anzeigen
    Da sagen meine Tests was anderes. Da wurde requestAnimationFrame kontinuierlich alle 20ms (= 50Hz = Frequenz des Monitors) aufgerufen obwohl überhaupt gar nichts irgendwie auf dem Bildschirm gerendert werden musste in den 10 Sekunden. Wie gesagt, ich hab' noch nicht einmal die Maus bewegt.
    ja, nochmal, das ist ja logisch, wenn nichts gerendert werden muss, muss er aufrufe zwischenschieben.


    Zitat Zitat von kkapsner Beitrag anzeigen
    Nein, das sagst du nicht. Du sagst "beim nächsten nötigen Rendern" und ich sage "beim nächsten möglichen Renderzeitpunkt". Das macht einen riesen Unterschied:
    wie soll der browser wissen, wann du einen button drückst, an dem ein clickhander hängt der das dom ändert?

    Zitat Zitat von kkapsner Beitrag anzeigen
    deines ist nicht vorherseh bar und meines schon (in gewissen Grenzen).
    nein, deines ist genausowenig vorhersehbar, nichtmal für den browser

    Zitat Zitat von kkapsner Beitrag anzeigen
    Wenn du Tests hast, die deine Meinung belegen, sehe ich sie mir gerne an. Den Test, der meine Meinung bestätig (so jedenfalls interpretiere ich das), hab' ich dir ja schon gezeigt.
    dein test war ja, wie du selbst sagst, ohne jegliches rendern, sogar ohne belastung.

    Zitat Zitat von kkapsner Beitrag anzeigen
    Wenn ich dich falsch verstehe, sag's bitte.
    ja, irgendwie glaube ich auch, daß wir aneinander vorbei reden

    Zitat Zitat von kkapsner Beitrag anzeigen
    Äh... ohne Monitor brauchst du gar kein Rendern, da man nichts sieht...
    das ist dem browser aber egal, der weiss nicht ob du den Monitor an oder aus hast oder nicht angeschlossen. der malt sein bild bei jeder änderung in sein devicecontext und gut.

    Zitat Zitat von kkapsner Beitrag anzeigen
    Natürlich rendert der nur, wenn er muss. Aber requestAnimationFrame stößt ja auch kein Rendern direkt an. Nur was darin passiert, kann ein Rendern anstoßen.
    ja, sagte ich was anderes? bis auf das "nur" in dem satz bin ich bei dir.

    Zitat Zitat von kkapsner Beitrag anzeigen
    Nö, wäre es nicht. Wenn ich im DOM ein verstecktest Element verändere muss nicht gerendert werden.
    ok

    Zitat Zitat von kkapsner Beitrag anzeigen
    ... ich kann mich nur wiederholen... der Callback wird aufgerufen, auch wenn kein Rendern nötig ist...
    nochmal, ja, dagegen sage ich ja gar nichts. ich sage aber, durch änderungen an sichtbaren dom-elementen, die keiner vorhersehen kann wird es auch aufgerufen. und diese sind unvorhersehbar.

    Zitat Zitat von kkapsner Beitrag anzeigen
    Technisches Zitat, auf das ich zusätzlich meine Meinung aufbaue:
    requestAnimationFrame method (Internet Explorer)
    Registers a function to call when the system is ready to update (repaint) the display.
    https://developer.mozilla.org/en-US/...AnimationFrame
    This will request that your animation function be called before the browser performs the next repaint.

  5. #20
    Avatar von kkapsner
    kkapsner ist offline Super Moderator
    registriert
    28-03-2008
    Beiträge
    17.760

    AW: Javascript: Funktion in Objekt übergeben und als Property speichern.

    Zitat Zitat von hesst Beitrag anzeigen
    Nein, aber wenn schon gerendert werden muss, kann man hier prima einen aufruf machen.
    Natürlich. Das bestreite ich auch nicht.


    Zitat Zitat von hesst Beitrag anzeigen
    einen möglichen renderzeitpunkt kennt der browser aber nach dem parsen nicht mehr.
    Sollte er aber (ich kenne jetzt die Browserimplementation nicht so gut, dass ich sagen könnte, dass jeder Browser das kann). Vor jedem neuen Bildschirmbildaufbau ist ein guter Renderzeitpunkt.

    Zitat Zitat von hesst Beitrag anzeigen
    ja, nochmal, das ist ja logisch, wenn nichts gerendert werden muss, muss er aufrufe zwischenschieben.
    Habe einen kleinen Test gemacht:
    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.kkapsner.de/modules/kkjs.load.js?modules=Timer,sprintf"></script>
    </head>
    <body>
    	Running...
    	<div id="timer"></div>
    	<div id="animationResult"></div>
    	<div id="normalResult"></div>
    <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 &plusmn; %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(){
    	kkjs.$("timer").innerHTML = this.getTimeString() + " (" + Math.random() + ")";
    });
    
    t2.start();
    t.start();
    </script>
    </body>
    </html>
    - hier wird so schnell wie möglich (window.setTimeout(fnc, 0)) ein neues Rendern nötig.
    Ergebnis:
    Code:
    Chrome:
    	animation: mean: 19.922310756972113 ± 1.395760598544772
    	setTimeout: mean: 4.93339911198816 ± 0.5161472008683037
    Firefox:
    	animation: mean: 20.044088176352705 ± 2.0263940055111886
    	setTimeout: mean: 4.156691604322527 ± 2.249589162193331
    IE:
    	animation: mean: 20.014 ± 1.240082255336312
    	setTimeout: mean: 3.360551075268817 ± 1.4161283800521635
    Opera:
    	animation: mean: 19.882703777335983 ± 1.3227475493268288
    	mean: 4.995504495504496 ± 0.1563819520112744
    kein großartiger Unterschied zum alten Test... (ich sehe einen Unterschied, wenn der Tab den Fokus nicht hat, aber es steht ja auch überall, dass dann die Frequenz reduziert ist. Auch wenn man wie wild rumscrollt, wird's langsamer im FF und IE).

    Auch sieht man, dass zwar ca. alle 4ms eigentlich ein neues Rendern nötig ist (der Zufallstext hat sich geändert) aber trotzdem nur alle 20ms der Repaint ausgeführt wird...


    Zitat Zitat von hesst Beitrag anzeigen
    wie soll der browser wissen, wann du einen button drückst, an dem ein clickhander hängt der das dom ändert?
    Was hat den das damit zu tun? Wie man im Test oben sieht, markiert der Browser dann nur "Rendern nötig" und macht das dann vor dem nächsten Renderzeitpunkt.


    Zitat Zitat von hesst Beitrag anzeigen
    nein, deines ist genausowenig vorhersehbar, nichtmal für den browser
    Wenn mein Monitor 50 Hz hat, hab' ich alle 20 ms einen idealen Renderzeitpunkt... das kann man wunderbar vorhersehen... also ich kann das.


    Zitat Zitat von hesst Beitrag anzeigen
    dein test war ja, wie du selbst sagst, ohne jegliches rendern, sogar ohne belastung.
    Oben neuer Test. Zwar immer noch ohne Belastung, aber Belastung macht JS prinzipiell langsam, da es mit einer sehr geringen Priorität läuft.


    Zitat Zitat von hesst Beitrag anzeigen
    ja, irgendwie glaube ich auch, daß wir aneinander vorbei reden
    Das kann gut sein - ich kann's nur nicht genau ausmachen, wo genau unser Kommunikationsproblem liegt...


    Zitat Zitat von hesst Beitrag anzeigen
    das ist dem browser aber egal, der weiss nicht ob du den Monitor an oder aus hast oder nicht angeschlossen. der malt sein bild bei jeder änderung in sein devicecontext und gut.
    Natürlich weiß der, welchen Monitor ich habe. Das komplette screen-Objekt wäre dann nicht realisierbar. Auch wären die ganzen Hardwarebeschleunigungssachen dann nicht möglich.


    Zitat Zitat von hesst Beitrag anzeigen
    ja, sagte ich was anderes?
    Gut - dann sind wir uns ja in dem Punkt einig.
    Zitat Zitat von hesst Beitrag anzeigen
    bis auf das "nur" in dem satz bin ich bei dir.
    Das "nur" ist doppeldeutig. Ich meinte nicht "nichts außer" sondern eher... ach streich' das "nur" einfach komplett aus dem Satz... und auch gleich noch das Komma; das ist falsch.

    Zitat Zitat von hesst Beitrag anzeigen
    nochmal, ja, dagegen sage ich ja gar nichts. ich sage aber, durch änderungen an sichtbaren dom-elementen, die keiner vorhersehen kann wird es auch aufgerufen. und diese sind unvorhersehbar.
    Der Test oben zeigt etwas anderes. Aber jetzt verstehe ich allmählich, was dein Punkt ist.


    Das "ready to update" interpretiere ich als "möglicher Renderzeitpunkt". Und wenn ich eine Renderengine schreiben würde, würde ich dann einen Repaint durchführen, wenn das für das Augabegerät optimal ist. Also alle 20ms bei einem 50Hz Monitor. Alles, was da dazwischen, würde ich immer zusammenfassen. Und so wie die Tests aussehen, scheint das bei den vieren auch der Fall zu sein - so interpretiere ich jedenfalls die Ergebnisse.

  6. #21
    tsseh ist offline Foren-Gott
    registriert
    19-05-2008
    Beiträge
    5.667

    AW: Javascript: Funktion in Objekt übergeben und als Property speichern.

    Zitat Zitat von kkapsner Beitrag anzeigen
    Sollte er aber (ich kenne jetzt die Browserimplementation nicht so gut, dass ich sagen könnte, dass jeder Browser das kann). Vor jedem neuen Bildschirmbildaufbau ist ein guter Renderzeitpunkt.
    was meinst du denn mit Bildschirmbildaufbau? den inhalt des grafikspeichers auf den monitor projizieren?
    damit hat der browser gar nichts zu tun. der browser ist nur ein fenster von 100en die angezeigt werden.
    der browser zeichnet nicht direkt in den grafikspeichers. das läuft änderungsgesteuert. unter windows jedenfalls und das wird überall ähnlich laufen.
    der browser macht eine änderung, die sich auf die anzeige auswirkt, daraufhin meldet er das dem BS (UpdateWindow)
    das BS sendet an den browser eine WM_PAINT message
    der browser zeichnet seine änderungen in ein abstraktes device
    um den rest kümmert sich das BS

    Code:
    Chrome:
    	animation: mean: 19.922310756972113 ± 1.395760598544772
    	setTimeout: mean: 4.93339911198816 ± 0.5161472008683037
    Firefox:
    	animation: mean: 20.044088176352705 ± 2.0263940055111886
    	setTimeout: mean: 4.156691604322527 ± 2.249589162193331
    IE:
    	animation: mean: 20.014 ± 1.240082255336312
    	setTimeout: mean: 3.360551075268817 ± 1.4161283800521635
    Opera:
    	animation: mean: 19.882703777335983 ± 1.3227475493268288
    	mean: 4.995504495504496 ± 0.1563819520112744
    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

    Zitat Zitat von kkapsner Beitrag anzeigen
    Auch sieht man, dass zwar ca. alle 4ms eigentlich ein neues Rendern nötig ist (der Zufallstext hat sich geändert) aber trotzdem nur alle 20ms der Repaint ausgeführt wird...
    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:
    Das menschliche Gehirn nimmt ab etwa 14 bis 16 Bildern pro Sekunde (individuell verschieden) aufeinanderfolgende Bilder als bewegte (aber nicht unbedingt ruckelfreie) Szene wahr
    warum sollte man da öfter ändern als überhaupt dargestellt wird?

    Zitat Zitat von kkapsner Beitrag anzeigen
    Wenn mein Monitor 50 Hz hat, hab' ich alle 20 ms einen idealen Renderzeitpunkt... das kann man wunderbar vorhersehen... also ich kann das.
    so arbeitet aber keine anwendung

    Zitat Zitat von kkapsner Beitrag anzeigen
    Der Test oben zeigt etwas anderes. Aber jetzt verstehe ich allmählich, was dein Punkt ist.
    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

  7. #22
    Avatar von kkapsner
    kkapsner ist offline Super Moderator
    registriert
    28-03-2008
    Beiträge
    17.760

    AW: Javascript: Funktion in Objekt übergeben und als Property speichern.

    Zitat Zitat von hesst Beitrag anzeigen
    was meinst du denn mit Bildschirmbildaufbau? den inhalt des grafikspeichers auf den monitor projizieren?
    Ja. Das was ich zu sehen bekomme.
    Zitat Zitat von hesst Beitrag anzeigen
    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.

    Zitat Zitat von hesst Beitrag anzeigen
    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.


    Zitat Zitat von hesst Beitrag anzeigen
    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.


    Zitat Zitat von hesst Beitrag anzeigen
    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.


    Zitat Zitat von hesst Beitrag anzeigen
    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 &plusmn; %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.

  8. #23
    tsseh ist offline Foren-Gott
    registriert
    19-05-2008
    Beiträge
    5.667

    AW: Javascript: Funktion in Objekt übergeben und als Property speichern.

    Zitat Zitat von kkapsner Beitrag anzeigen
    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.
    sicher
    "projiziert" - gefällt dir nicht? mir fiel nichts besseres ein

    Zitat Zitat von kkapsner Beitrag anzeigen
    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.
    meiner nicht, so wie es zwischenschritte geben muss, ist es sinnvoll (nicht zwingend) die updaterate auf einen wert zu begrenzen. ob das die monitorfrequez ist kann ich nicht sagen, scheint aber so. vermutet hätte ich einen wert leicht größer als diese.


    Zitat Zitat von kkapsner Beitrag anzeigen
    Das glaube ich nicht. Alles was eine flüssige Darstellung braucht wird sich auf die Grafikkarte und damit den Monitor abstimmen.
    ist aber so, die einen haben eine fps von 120 die anderen von 30, je nach cpu/grafikkarte

    Zitat Zitat von kkapsner Beitrag anzeigen
    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).
    Tearing
    deshalb wird ja ab vista auch gepuffert
    es gibt im bereich der spiele, die directx nutzen auch möglichkeiten sich mit der grafikkarte zu syncronisieren, das wird aber immer nur optional angeboten, weil du damit deine fps künstlich begrenzt, da du immer wartest, bei 50Hz monitor und ner 51er fps kein problem, aber aus ner 49er fps die möglich wären machst du 25.

    Zitat Zitat von kkapsner Beitrag anzeigen
    Zeig' mir bitte deinen Code.
    reich ich morgen nach
    EDIT:
    Code:
    <!DOCTYPE html>
    <html>
      <head>
        <title>test</title>
        <style>
          .animation {
            position:absolute;
            width:20px;
            top:40px;
            left:20px;
            color:#ffffff;
            background-color:#00ff00;
          }
        </style>
        <script>
          window.addEventListener("load", function()
          {
            var addButtonClickHandler = function()
            {
              var elems = 0;
              var div = null;
              var test = document.getElementById("test");
              document.getElementById("click").addEventListener("click", function()
              {
                if (!(elems++ % 10))
                {
                  div = document.createElement("div");
                  var text = document.createTextNode("div");
                  div.appendChild(text);
                  test.appendChild(div);
                }
                else
                {
                  var spawn = document.createElement("spawn");
                  var text = document.createTextNode("spawn");
                  spawn.appendChild(text);
                  div.appendChild(spawn);
                }
              });
            };
            addButtonClickHandler();
            
            var analyze = function(timings)
            {
              var animationTime = 0;
              for (var i = 1; i < timings.length; ++i)
              {
                animationTime += timings[i];
              }
              animationTime /= (timings.length - 1);
              var deviants = 0;
              var epsilonIdx = 0;
              var animationEpsilon = 0;
              var animationResult = "";
              for (var i = 1; i < timings.length; ++i)
              {
                animationResult += timings[i] + "; ";
                if (Math.abs(animationTime - timings[i]) > animationEpsilon)
                {
                  epsilonIdx = i;
                  animationEpsilon = Math.abs(animationTime-timings[i]);
                }
                if (Math.abs(animationTime - timings[i]) > 1)
                {
                  ++deviants;
                }
                
              }
              document.getElementById("animationResult").innerHTML = "animation: " + animationTime + " +- " + animationEpsilon;
              document.getElementById("animationResult").innerHTML += "<br>" + animationResult;
              document.getElementById("animationResult").innerHTML += "<br>" + "<br> max. Abweichung bei: " + epsilonIdx + " Wert: " + timings[epsilonIdx] + "<br>" + " Abweichungen: " + deviants;
            }
            
            var animate = function()
            {
              var animationTiming = [];
              var animationTime = 0;
              var animationInc = 1;
              
              var animationDiv = document.getElementsByClassName("animation")[0];
              animationDiv.style.height = "20px";
              var animationLoop = function()
              {
                var time = new Date();
                animationTiming.push(time - animationTime);
                var height = parseInt(animationDiv.style.height);
                if (height > 100 || height < 20)
                {
                  animationInc *= -1;
                }
                animationDiv.style.height = (height + animationInc) + "px";
                animationTime = time;
                if (animationTiming.length >= 1000)
                {
                  animationDiv.style.height = "0px";
                  analyze(animationTiming);
                }
                else
                {
                  requestAnimationFrame(animationLoop);
                }
              }
              requestAnimationFrame(animationLoop);
            };
            animate();
          });
        </script>
      </head>
      <body>
    	  <div id="animationResult"></div>
    	  <div class="animation"></div>
        <button id="click" type="button">test</button>
        <div id="test"></div>
      </body>
    </html>
    :TIDE

    Zitat Zitat von kkapsner Beitrag anzeigen
    Hat sich bei der Messung der Mittelwert verschoben? Bitte Zahlen.
    nein, war meistens 16 oder 17 ms wenn es dann mal 20 wurden, war der nächste aufruf nach 12/13 ms

    Zitat Zitat von kkapsner Beitrag anzeigen
    Ich denke mal, dass bei deinem Test das Erzeugen des DOM-Elements das ganze unter Last legt
    sind wir wieder bei dem punkt, wo es eigentlich schon egal wäre.
    Geändert von tsseh (06-05-2014 um 09:48 Uhr)

  9. #24
    Avatar von kkapsner
    kkapsner ist offline Super Moderator
    registriert
    28-03-2008
    Beiträge
    17.760

    AW: Javascript: Funktion in Objekt übergeben und als Property speichern.

    Zitat Zitat von hesst Beitrag anzeigen
    sicher
    Das war ein Teil meines Punktes... gut, dass wir uns da einig sind.
    Zitat Zitat von hesst Beitrag anzeigen
    "projiziert" - gefällt dir nicht? mir fiel nichts besseres ein
    Mir fällt auch nichts wirklich besseres ein

    Zitat Zitat von hesst Beitrag anzeigen
    meiner nicht, so wie es zwischenschritte geben muss
    Warum muss es beim Repaint (das meine ich mit dem Rendern) Zwischenschritte geben? Beim DOM-Layout und Reflow gebe ich dir Recht (der Reflow wird ja sogar zwischen einzelnen JS-Statements gemacht, wenn er nötig ist). Aber beim Repaint?
    Zitat Zitat von hesst Beitrag anzeigen
    , ist es sinnvoll (nicht zwingend) die updaterate auf einen wert zu begrenzen. ob das die monitorfrequez ist kann ich nicht sagen, scheint aber so. vermutet hätte ich einen wert leicht größer als diese.
    Natürlich ist das nicht zwingend. Das war auch nicht mein Punkt. Aber, wie du sagst, scheinen die Browser das zu machen und das ist mein Punkt.

    Zitat Zitat von hesst Beitrag anzeigen
    ist aber so, die einen haben eine fps von 120 die anderen von 30, je nach cpu/grafikkarte
    Äh... das wiederspricht sich irgendwie für micht mit
    Zitat Zitat von hesst Beitrag anzeigen
    es gibt im bereich der spiele, die directx nutzen auch möglichkeiten sich mit der grafikkarte zu syncronisieren
    Und warum sollte ich 120 fps berechnen, wenn der Benutzer nur 50 fps sieht? Das ist doch komplette Verschwendung.

    Zitat Zitat von hesst Beitrag anzeigen
    , das wird aber immer nur optional angeboten, weil du damit deine fps künstlich begrenzt, da du immer wartest, bei 50Hz monitor und ner 51er fps kein problem, aber aus ner 49er fps die möglich wären machst du 25.
    Wenn ich die 50 fps nicht schaffe, ergibt es auch keinen Sinn, sich mit dem Monitor zu synchronisieren...

    Zitat Zitat von hesst Beitrag anzeigen
    reich ich morgen nach
    also bei mir ist kein Unterschied, ob ich die Elemente erzeuge oder nicht - und auch kein Unterschied zu meinem Test... könnte daran liegen, dass ich Win7 hab'... da scheinen sich die Browser anders zu verhalten als in XP. Gut zu wissen - für das nächste halbe Jahr...
    Wobei ich das Verhalten meiner Browser sinnvoller finde (ich weiß, dass du das nicht so siehst).


    Zitat Zitat von hesst Beitrag anzeigen
    nein, war meistens 16 oder 17 ms wenn es dann mal 20 wurden, war der nächste aufruf nach 12/13 ms
    Ja, das ist bei mir genauso und würde ja dafür sprechen, dass es mit dem Monitor synchronisiert ist


    Zitat Zitat von hesst Beitrag anzeigen
    sind wir wieder bei dem punkt, wo es eigentlich schon egal wäre.
    Natürlich ist es egal. Verlassen kann man sich sowieso nicht drauf. Ich bin nur der Meinung, dass man sich auf window.setTimeout noch weniger verlassen kann.

    Deswegen hab ich oben ja auch
    Zitat Zitat von kkapsner Beitrag anzeigen
    Etwas besser ist window.requestAnimationFrame() , aber auch nicht perfekt
    geschrieben.

  10. #25
    tsseh ist offline Foren-Gott
    registriert
    19-05-2008
    Beiträge
    5.667

    AW: Javascript: Funktion in Objekt übergeben und als Property speichern.

    Zitat Zitat von kkapsner Beitrag anzeigen
    Warum muss es beim Repaint (das meine ich mit dem Rendern) Zwischenschritte geben?
    es muss Zwischenschritte bei der animation geben, auch wenn sonst kein Rendern nötig ist. das meinte ich.

    Zitat Zitat von kkapsner Beitrag anzeigen
    Äh... das wiederspricht sich irgendwie für micht mit

    Und warum sollte ich 120 fps berechnen, wenn der Benutzer nur 50 fps sieht? Das ist doch komplette Verschwendung.
    so läuft das aber, es wird berechnet, was der rechner hergibt.

    [QUOTE=kkapsner;379878]also bei mir ist kein Unterschied, ob ich die Elemente erzeuge oder nicht - und auch kein Unterschied zu meinem Test... könnte daran liegen, dass ich Win7 hab'... da scheinen sich die Browser anders zu verhalten als in XP. [QUOTE=kkapsner;379878]
    Ich hab das auch unter Win 7 getestet.

    [QUOTE=kkapsner;379878]Ja, das ist bei mir genauso und würde ja dafür sprechen, dass es mit dem Monitor synchronisiert ist [QUOTE=kkapsner;379878]
    nee, das spricht für einen festen timer von 16/17 ms, bei dem nicht berechnet wird, wenn seit dem letzten timerevent schon ein rendern erfolgte und somit schon berechnet wurde, ...
    ... wobei dann immer auf ein 13ms wert ein 20 ms wert folgen müsste, werd ich mir nochmal ansehen, wierum das nun genau war.

  11. #26
    Avatar von kkapsner
    kkapsner ist offline Super Moderator
    registriert
    28-03-2008
    Beiträge
    17.760

    AW: Javascript: Funktion in Objekt übergeben und als Property speichern.

    Zitat Zitat von hesst Beitrag anzeigen
    es muss Zwischenschritte bei der animation geben, auch wenn sonst kein Rendern nötig ist. das meinte ich.
    Ach so. Klar muss es bei der Animation Zwischenschritte geben... aber das hab' ich auch nie abgestritten.

    Zitat Zitat von hesst Beitrag anzeigen
    so läuft das aber, es wird berechnet, was der rechner hergibt.
    So läuft das in schlecht geschriebener Software, die immer 100% meiner CPU/GPU beansprucht... sowas wird bei mir soft wieder deinstalliert.

    Zitat Zitat von hesst Beitrag anzeigen
    Ich hab das auch unter Win 7 getestet.
    Dann ist es seltsam...

    Zitat Zitat von hesst Beitrag anzeigen
    nee, das spricht für einen festen timer von 16/17 ms, bei dem nicht berechnet wird, wenn seit dem letzten timerevent schon ein rendern erfolgte und somit schon berechnet wurde, ...
    ... wobei dann immer auf ein 13ms wert ein 20 ms wert folgen müsste, werd ich mir nochmal ansehen, wierum das nun genau war.
    Die 50Hz (bzw. bei dir 60Hz) des Monitors sind auch ein fester Timer... und solange die beiden Timer mit der gleichen Frequenz arbeiten, kommt das (fast) auf das Gleiche raus.

  12. #27
    tsseh ist offline Foren-Gott
    registriert
    19-05-2008
    Beiträge
    5.667

    AW: Javascript: Funktion in Objekt übergeben und als Property speichern.

    Zitat Zitat von kkapsner Beitrag anzeigen
    So läuft das in schlecht geschriebener Software, die immer 100% meiner CPU/GPU beansprucht... sowas wird bei mir soft wieder deinstalliert.
    wir reden hier über spiele?! nur da macht es überhaupt sinn über fps zu reden. und da ist es so. das witzige an der sache ist ja, daß es dann immer noch leute gibt, die behaupten den unterschied zw. 100 und 120 fps zu sehen. und das lange bevor es 120 hz monitore gab. Wieviel fps habt ihr so
    Bei normalen Anwendungen hast du überhaupt keine fps, da dort in der regel nur auf usereingaben gewartet wird. wenn dann mal eine kommt, wird gerendert.

    Zitat Zitat von kkapsner Beitrag anzeigen
    Die 50Hz (bzw. bei dir 60Hz) des Monitors sind auch ein fester Timer... und solange die beiden Timer mit der gleichen Frequenz arbeiten, kommt das (fast) auf das Gleiche raus.
    ob ich einen timer habe, der ungefähr der monitorfrequenz entspricht oder synchron zur monitorfrequenz berechne ist ein himmelweiter unterschied.

  13. #28
    Avatar von kkapsner
    kkapsner ist offline Super Moderator
    registriert
    28-03-2008
    Beiträge
    17.760

    AW: Javascript: Funktion in Objekt übergeben und als Property speichern.

    Zitat Zitat von hesst Beitrag anzeigen
    wir reden hier über spiele?!
    Nicht nur. Ich rede von allem, das eine Animation flüssig darstellen soll.
    Zitat Zitat von hesst Beitrag anzeigen
    Super!

    Zitat Zitat von hesst Beitrag anzeigen
    Bei normalen Anwendungen hast du überhaupt keine fps, da dort in der regel nur auf usereingaben gewartet wird. wenn dann mal eine kommt, wird gerendert.
    Bei den meisten Anwendungen stimmt das, aber wenn ich mir z.B. ein Video ansehe oder ein 3D-Modell gerade animiert ansehe, kann man schon auch von fps reden.

    Zitat Zitat von hesst Beitrag anzeigen
    ob ich einen timer habe, der ungefähr der monitorfrequenz entspricht oder synchron zur monitorfrequenz berechne ist ein himmelweiter unterschied.
    Wer hat denn was von "ungefähr" gesagt? Wenn die Frequenzen nichr genau übereinstimmen, ist das natürlich ein Unterschied.

Seite 2 von 2 ErsteErste 12

Ähnliche Themen

  1. Javascript String-Objekt um eine Funktion erweitern?
    Von Flashbaer im Forum JavaScript
    Antworten: 2
    Letzter Beitrag: 18-06-2010, 21:55
  2. Variablen aus PHP an Javascript Funktion übergeben
    Von insanity wolfi im Forum JavaScript
    Antworten: 2
    Letzter Beitrag: 27-05-2010, 11:51
  3. Objekt in einer Funktion übergeben
    Von dsentker im Forum JavaScript
    Antworten: 9
    Letzter Beitrag: 15-10-2008, 17:39
  4. Objekt an Klassen-Funktion übergeben
    Von slayer2206 im Forum JavaScript
    Antworten: 5
    Letzter Beitrag: 18-01-2007, 17:07
  5. Javascript mit speichern Funktion !!!
    Von badboy0014 im Forum JavaScript
    Antworten: 0
    Letzter Beitrag: 05-08-2006, 14:55

Stichworte

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •