setinterval = lüge?
2 0 1 0 
Gernot Back
0 0 0 
Struppi
0
0 Struppi
4 setinterval läuft so schnell, wie vorgesehen
0 0 
Tim Tepaße
0 Struppi
0
setinterval = lüge?
Hi Leude,
habe das Problem das ich ne simple "moveDiv" Funktion mit setinterval 1ms aufrufe, nur Leider haut das nich so hin wie ich mir das Vorstelle. Soll heisen das alles was setinterval unter 50 ms betrifft keinen Unterschied macht (div wandert gleichschnell nach unten egal ob 1ms oder 50ms).
Woran kann das nur liegen, das ist simpelster code ohne Berechnungen.....
(habe das bei komplexeren selstgecodeten Funktionen festgestellt und nun auf setintervall runtergebrochen)
Bitte schreibt mir eure Erfahrungen bzw. Lösungen zu dem Problem, Danke.
Hier noch mein Code (ne html page):
<html>
<head>
<title>test3</title>
<style type="text/css">
#test1 {background-color: #00FF33;left: 50px;top: 10px;position: absolute; width: 50px;height: 20px;}
#test2 {background-color: #FF0000;left: 150px;top: 10px;position: absolute; width: 50px;height: 20px;}
#test {background-color: #000033;left: 50px;top: 50px;position: absolute; width: 100px;height: 100px;}
</style>
<script type="text/javascript">
function interval(delay) {
xdelay = delay;
delayinter = setInterval("move();", xdelay);
}
function intervalstop() {
clearInterval(delayinter);
}
function move() {
xtop = document.getElementById('test').offsetTop;
document.getElementById('test').style.top = xtop + 1;
}
</script>
</head>
<body>
<div id="test1" onClick="interval(1)">start</div>
<div id="test2" onClick="intervalstop()">stop</div>
<div id="test"></div>
</body>
</html>
-
Soll heisen das alles was setinterval unter 50 ms betrifft keinen Unterschied macht (div wandert gleichschnell nach unten egal ob 1ms oder 50ms).
Woran kann das nur liegen, das ist simpelster code ohne Berechnungen.....
Tja, woran nur, woran nur …
a) Dir ist nicht klar, wie "lang" 1 Millisekunde ist? Als Orientierung für die Laufzeiten bei Animationen gelten etwa 40 Millisekunden pro Bild bzw. um und bei 25 Bilder pro Sekunde. Und jetzt sage nicht, Filmschaffende erzählen diesbezüglich seit über 100 Jahren Lügen.
b) Wenn im Kino ein Auto schneller fahren soll, dann lässt man auch nicht den Film schneller laufen, sondern vergrößert quasi den Abstand, den das Auto zwischen zwei Bildern schafft.
-
a) Dir ist nicht klar, wie "lang" 1 Millisekunde ist? Als Orientierung für die Laufzeiten bei Animationen gelten etwa 40 Millisekunden pro Bild bzw. um und bei 25 Bilder pro Sekunde. Und jetzt sage nicht, Filmschaffende erzählen diesbezüglich seit über 100 Jahren Lügen.
Was hat das mit seinem Anliegen zu tun?
b) Wenn im Kino ein Auto schneller fahren soll, dann lässt man auch nicht den Film schneller laufen, sondern vergrößert quasi den Abstand, den das Auto zwischen zwei Bildern schafft.
Sind wir hier im Kino?
-
Als Orientierung für die Laufzeiten bei Animationen gelten etwa 40 Millisekunden pro Bild bzw. um und bei 25 Bilder pro Sekunde. Und jetzt sage nicht, Filmschaffende erzählen diesbezüglich seit über 100 Jahren Lügen.
Was hat das mit seinem Anliegen zu tun?
Du hast deine Aufgabenstellung offensichtlich nicht verstanden. Es soll ein Kästchen im Browserfenster verschoben werden.
Sind wir hier im Kino?
Glaubst du, da würde ein kleines Männchen im Monitor sitzen, dass besagtes Kästchen auf dem Bildschirm von A nach B schiebt? Oder könnte es nicht etwa doch sein, dass eine Bewegung auf dem Bildschirm nach dem gleichen Prinzip abläuft wie jeder Kinofilm, nämlich dass eine schnelle Abfolge von Einzelbildern eine Bewegung erscheinen lässt?
Falls letzteres, aus welchem Grunde sollte am vom Computer gesteuerten Bildschirm eine Bilderfolge für das menschliche Auge erst dann flüssig erscheinen, wenn sie mit vierzigfacher Geschwindigkeit im Vergleich zu Film und Fernsehen abläuft? (Erspare dir Erklärungsversuche, sie tut es nicht.)Ergo: Pro Bild bzw. Bewegung 1 Millisekunde zu fordern ist so sinnlos wie mit Kanonen auf Spatzen zu schießen und zeigt bestenfalls, dass sich da jemand nicht über das Prinzip im Klaren ist. Oder für seine Experimente die falsche Methode gewählt hat.
-
Hallo Gonzo,
Ergo: Pro Bild bzw. Bewegung 1 Millisekunde zu fordern ist so sinnlos wie mit Kanonen auf Spatzen zu schießen und zeigt bestenfalls, dass sich da jemand nicht über das Prinzip im Klaren ist. Oder für seine Experimente die falsche Methode gewählt hat.
Du sprichst mir aus der Seele.
Gruß Gernot
--
super me -
Ergo: Pro Bild bzw. Bewegung 1 Millisekunde zu fordern ist so sinnlos wie mit Kanonen auf Spatzen zu schießen und zeigt bestenfalls, dass sich da jemand nicht über das Prinzip im Klaren ist. Oder für seine Experimente die falsche Methode gewählt hat.
Darum _geht_ es doch gar nicht! Es geht darum, dass es keinen Unterschied zwischen einer und zwei Millisekunden gibt! Beides ist für den Betrachter gleichschnell, das hat damit aber gar nichts zu tun. Schiebt sich das Kästchen nämlich nur alle zwei Millisekunden um einen Pixel nach oben, ist es vielleicht erst nach 3 Sekunden ganz oben, wenn es sich aber jede Millisekunde um einen Pixel nach oben verschiebt, schon in 1,5 Sekunden.
Darum ging es und nicht um's Kino...
-
Hi,
Darum _geht_ es doch gar nicht! Es geht darum, dass es keinen Unterschied zwischen einer und zwei Millisekunden gibt!
Wenn du anderen sagst, sie wuerden am Thema vorbei antworten - dann wuerde ich aber selber ein bisschen mehr aufpassen, denn mit der Aussage bist du wohl ziemlich auf verbalem Glatteis :-)
Beides ist für den Betrachter gleichschnell, das hat damit aber gar nichts zu tun. Schiebt sich das Kästchen nämlich nur alle zwei Millisekunden um einen Pixel nach oben, ist es vielleicht erst nach 3 Sekunden ganz oben, wenn es sich aber jede Millisekunde um einen Pixel nach oben verschiebt, schon in 1,5 Sekunden.
Und genau das hat Gonzo in seiner vorherigen Antwort beschrieben -
Darum ging es und nicht um's Kino...
- und dabei der Anschaulichkeit halber den Vergleich mit dem Kinofilm hergenommen, der hier alles andere als ein hinkender ist, weil "Animation"/Bewegung in beiden Faellen gleich funktioniert: Durch eine Verschiebung von Bildinhalten gegenueber dem vorherigen "Frame" in einem definierten Zeitintervall.
MfG ChrisB
-
Hi,
Darum _geht_ es doch gar nicht! Es geht darum, dass es keinen Unterschied zwischen einer und zwei Millisekunden gibt!
Wenn du anderen sagst, sie wuerden am Thema vorbei antworten - dann wuerde ich aber selber ein bisschen mehr aufpassen, denn mit der Aussage bist du wohl ziemlich auf verbalem Glatteis :-)
Beides ist für den Betrachter gleichschnell, das hat damit aber gar nichts zu tun. Schiebt sich das Kästchen nämlich nur alle zwei Millisekunden um einen Pixel nach oben, ist es vielleicht erst nach 3 Sekunden ganz oben, wenn es sich aber jede Millisekunde um einen Pixel nach oben verschiebt, schon in 1,5 Sekunden.
Und genau das hat Gonzo in seiner vorherigen Antwort beschrieben -
Nein, er hat nichts über den Weg gesagt, den das Kästchen zurücklegt. Und darum ging es dem OP. Er hat nur erklärt, dass man ab 25 Bildern/Sekunde eine flüssige Bewegung wahrnimmt und sich das bei 25+n Bildern/Sekunde nicht ändert. Dagegen sage ich auch nichts, aber darum ging es dem OP nicht.
Darum ging es und nicht um's Kino...
- und dabei der Anschaulichkeit halber den Vergleich mit dem Kinofilm hergenommen, der hier alles andere als ein hinkender ist, weil "Animation"/Bewegung in beiden Faellen gleich funktioniert: Durch eine Verschiebung von Bildinhalten gegenueber dem vorherigen "Frame" in einem definierten Zeitintervall.
Der OP wollte gar nicht wissen, wie eine Bewegung funktioniert
Ich zietiere mal:
"Soll heisen das alles was setinterval unter 50 ms betrifft keinen Unterschied macht (div wandert gleichschnell nach unten egal ob 1ms oder 50ms)."Es wandert _gleichschnell_ nach unten! _Gleichschnell_ ist der Begriff, um den es geht. Nicht darum, ob das ganze flüssig ist oder nicht.
Stimmt's oder hab ich Recht? Oder beides? :)
-
Hi,
Stimmt's oder hab ich Recht? Oder beides? :)
Hoechstens eins von beiden gestehe ich dir zu :-)
MfG ChrisB
-
Darum _geht_ es doch gar nicht! Es geht darum, dass es keinen Unterschied zwischen einer und zwei Millisekunden gibt!
Das ist nichtmal theoretisch technisch möglich, zumindest nicht mit aktuellen Rechnern. wie der OP schon festgestellt hat, braucht der Rechner je nach System und Browser viel länger, erst wenn der Interval länger ist, wirst du den Unterschied merken.
Struppi.
-
Darum _geht_ es doch gar nicht! Es geht darum, dass es keinen Unterschied zwischen einer und zwei Millisekunden gibt!
Das ist nichtmal theoretisch technisch möglich,
Habe ich das behauptet? Ich habe nur gesagt, was der OP meinte/wissen wollte.
-
-
Darum _geht_ es doch gar nicht!
Schiebt sich das Kästchen nämlich nur alle zwei Millisekunden um einen Pixel nach oben, ist es vielleicht erst nach 3 Sekunden ganz oben, wenn es sich aber jede Millisekunde um einen Pixel nach oben verschiebt, schon in 1,5 Sekunden.
Und? Die Aufgabenstellung, eine Animation mit 1ms pro Bild abzuspielen, ist trotzdem sinnlos. Wenn Herr/Frau/Fräulein Eisfeld sein Kästchen in 1,5 statt 3 Sekunden oben haben will, dann soll er/sie/es die Schrittweite vergrößern und nicht die Bildfrequenz erhöhen, genauso so, wie ich es im zweiten Teil meiner Antwort geschrieben habe:
Wenn im Kino ein Auto schneller fahren soll, dann lässt man auch nicht den Film schneller laufen, sondern vergrößert quasi den Abstand, den das Auto zwischen zwei Bildern schafft.
Es geht darum, dass es keinen Unterschied zwischen einer und zwei Millisekunden gibt! Beides ist für den Betrachter gleichschnell
Gut, das ist so, der Browser des Fragesteller ist scheinbar zu langsam. Das hat der Fragesteller festgestellt, das kann hier nur bestätigt werden. Was hat er von dieser Bestätigung? Nichts.
Deshalb war ich so frei und habe mir das eigentliche Problem vorgenommen, jenes, das ihn erst zu besagter Beobachtung geführt hat, und das war die Animation eines Kästchens - womit wir wieder beim Film wären. Was hat er von dieser, meiner Antwort? Er schraubt a) die Belastung seines Browsers um den Faktor 40 runter und bekommt b) sein Kästchen so schnell von A nach B, wie immer es ihm beliebt.
Kannst du sagen, was du willst, ich finde meine Antwort überaus hilfreich.
-
Darum _geht_ es doch gar nicht!
Schiebt sich das Kästchen nämlich nur alle zwei Millisekunden um einen Pixel nach oben, ist es vielleicht erst nach 3 Sekunden ganz oben, wenn es sich aber jede Millisekunde um einen Pixel nach oben verschiebt, schon in 1,5 Sekunden.
Und? Die Aufgabenstellung, eine Animation mit 1ms pro Bild abzuspielen, ist trotzdem sinnlos. Wenn Herr/Frau/Fräulein Eisfeld sein Kästchen in 1,5 statt 3 Sekunden oben haben will, dann soll er/sie/es die Schrittweite vergrößern und nicht die Bildfrequenz erhöhen, genauso so, wie ich es im zweiten Teil meiner Antwort geschrieben habe:
Wir können nur mutmaßen, ob er das will. Seine konkrete Frage war: "Woran kann das nur liegen" (dass es keinen Unterschied macht).
Und deine Antwort war an seiner Frage vorbei. Vielleicht nicht an seiner eigentlichen Frage und genau das habe ich gesagt. Dazu, ob dein Beitrag nun hilfreich ist oder nicht, habe ich mich gar nicht geäußert.
Wenn im Kino ein Auto schneller fahren soll, dann lässt man auch nicht den Film schneller laufen, sondern vergrößert quasi den Abstand, den das Auto zwischen zwei Bildern schafft.
Gut, da magst du Recht haben (oder habe ich das irgendwo angezweifelt)? Ab abgesehen davon: in manchen Fällen, funktioniert es nicht, einfach die Pixelzahl zu verändern, weil man das ganze z.b. schlecht um 1,5 Pixel nach oben verschieben kann. Die Zeit hingegen kann man sehr flexibel verändern ohne dass es Probleme gibt.
Es geht darum, dass es keinen Unterschied zwischen einer und zwei Millisekunden gibt! Beides ist für den Betrachter gleichschnell
Nein, unterschiedlich schnell. Was du meinst ist, dass es für den Betrachter gleichflüssig wirkt.
Gut, das ist so, der Browser des Fragesteller ist scheinbar zu langsam. Das hat der Fragesteller festgestellt, das kann hier nur bestätigt werden. Was hat er von dieser Bestätigung? Nichts.
Doch, er weiß nun, warum seine Änderungen nicht den gewünschten Effekt bewirkten. Hätte ja auch sein können, dass die Funktion generell alle Angeben unter 100 Millisekunden (ausgedacht) auf 100 setzt?
Deshalb war ich so frei und habe mir das eigentliche Problem vorgenommen,
Nein, du hast dir das _vermutlich_ eigentliche problem vorgenommen.
jenes, das ihn erst zu besagter Beobachtung geführt hat, und das war die Animation eines Kästchens - womit wir wieder beim Film wären. Was hat er von dieser, meiner Antwort? Er schraubt a) die Belastung seines Browsers um den Faktor 40 runter und bekommt b) sein Kästchen so schnell von A nach B, wie immer es ihm beliebt.
Kannst du sagen, was du willst, ich finde meine Antwort überaus hilfreich.
Klar, für diese Problemstellung sicherlich. Nicht aber für seine, die er geäußert hat. Können wir uns darauf einigen? :)
-
-
-
-
-
-
Woran kann das nur liegen, das ist simpelster code ohne Berechnungen.....
Ist es das?
function move() {
xtop = document.getElementById('test').offsetTop;
document.getElementById('test').style.top = xtop + 1;
}Das ist durchaus komplexer Code, für den der Browser mit Sicherheit länger als ein paar Millisekunden braucht.
Struppi.
-
Moin!
habe das Problem das ich ne simple "moveDiv" Funktion mit setinterval 1ms aufrufe, nur Leider haut das nich so hin wie ich mir das Vorstelle. Soll heisen das alles was setinterval unter 50 ms betrifft keinen Unterschied macht (div wandert gleichschnell nach unten egal ob 1ms oder 50ms).
setIntervall ruft die Funktion solange nicht neu auf, wie Javascript-Code ausgeführt wird.
Konkreter erzählt es John Resig (Autor von jQuery) in diesem Posting seines Blogs (englisch).
Wichtig zu wissen ist: Javascript ist in den Browsern eine Single-Task-Programmiersprache. Es wird immer nur eine einzige Programmzeile zur Zeit ausgeführt, es gibt keinerlei Interrupts, die den Programmablauf unterbrechen und anderswo in den Code springen - deshalb ist es auch absolut irrelevant, wie schnell hintereinander setInterval eine Funktion aufrufen _will_ - entscheidend ist, wie lange in Millisekunden der Browser zur Ausführung dieser Funktion tatsächlich benötigt, denn die schnellstmögliche Ausführung einer Animation bedeutet, dass diese Funktion andauernd, d.h. immer wieder von vorn und ohne Wartezeit, ausgeführt wird, so schnell es geht.
Woran kann das nur liegen, das ist simpelster code ohne Berechnungen.....
(habe das bei komplexeren selstgecodeten Funktionen festgestellt und nun auf setintervall runtergebrochen)getElementById ist beispielsweise eine Funktion, deren Ausführung relativ lange dauert - jedenfalls verglichen mit der Variante, das Funktionsergebnis einmalig in einer Variablen zwischenzuspeichern und jeweils dort wieder abzurufen.
Es hat allerdings relativ wenig Sinn, eine Animationsfunktion zu schreiben, die man häufiger als alle 50 Millisekunden aufrufen muß, um die gewünschte Geschwindigkeit zu erreichen. Zum einen behindert eine andauern und pausenlos laufende Animation die Ausführung von anderen Javascripten (z.B. onclick-Events), und zweitens wirkt laufendes Javascript auch auf den restlichen Rechner.
- Sven Rautenberg
--
"Love your nation - respect the others."-
Hi Leude,
ich nochma, also danke für die Posting (egal ob gut oder "bös" gesonnen).
Nun ein paar Statements von mir ^^:Mir ist klar das es keine Sinn mach eine bewegung überm Ticker von 24 FPS (ca 40 ms) zu machen (Thema Menschliches Auge), aber darum ging es mir garnicht.
Wenn das Thread Thema ´n bissl danebengegriffen war: Hiermit entschuldigung!Aber nun zum Informativsten Beitrag von Sven Rautenberg:
Danke nochmal ;-DAber nochmal zum Prob, du hast geschrieben Zitat:
<---
jedenfalls verglichen mit der Variante, das Funktionsergebnis einmalig in einer Variablen zwischenzuspeichern und jeweils dort wieder abzurufen.
--->Nur Howtodo that Stuff?
-in ne var schreiben krieg ich hin!
-aber wie ohne den ständigen intervall immerwieder in die pos von nem div schreiben? - nochmal ne function mit setintervall macht ja meiner ansicht nach ned viel sinn!So denk ich ma meintest du des auch nicht - aber wie dann mir fehlt der richtige stoss in die richtige richtung (oder die funtion die das eben so macht.
also wer net wenn da nochma n oaar postings oder auch nur eins (das richtige) dazukommt. Binn derweil auf der suche nach der richtigen function und poste sie wenn ich bin fündig geworden.
So das wars JODA hat gesprochen. Have a nice Day Deville.-
Hallo,
Aber nochmal zum Prob, du hast geschrieben Zitat:
<---
jedenfalls verglichen mit der Variante, das Funktionsergebnis einmalig in einer Variablen zwischenzuspeichern und jeweils dort wieder abzurufen.
--->Nur Howtodo that Stuff?
-in ne var schreiben krieg ich hin!
-aber wie ohne den ständigen intervall immerwieder in die pos von nem div schreiben? - nochmal ne function mit setintervall macht ja meiner ansicht nach ned viel sinn!Also, ich verstehe das so: Statt in deiner function move() jedesmal xtop neu zu ermittlen mit
xtop = document.getElementById('test').offsetTop;
würde man normalerweise xtop nur eimal messen und dann separat verwalten, d.h. einfach mit
xTop = xtop + 1; ( bzw. xTop += 1;)
erhöhen, um es dann mit
document.getElementById('test').style.top = xtop;
zuzuweisen.Das zweite document.getElementById('test') für die Zuweisung kann man sich dann auch gleich sparen, indem man das Objekt nur einmal ermittelt und dann in einer Variablen (z.B. "testdiv") vorhält, so dass die Verschiebung jeweils mit
testdiv.style.top = xtop; //(nach genanter Erhöhung von xtop))
erldedigt ist.Gruß, Don P
-
Danke erstmal,
und an der Stelle muss ich gleich sagen das der von mir gepostete Code Müll ist, den setzte ich nicht ein, der war nur zur Visualisierung gedacht!
Anbei noch Daten die das setinterval Problem nochmals verdeutlichen.
Hierbei gilt es zu erwähnen:
Das ich die Position des Divs nur einmal abfrage und zwar am Anfang und nicht in der setintervall Funktion!
Dann lasse ich weiterhin in der setinterval Funktion nur eine var hochzählen! (Mittlerweile!)
Die Funktion "Neue position in div-position schreiben" habe ich ausgeschlossen!Same problem as before!
Nun habe ich Tests durchgeführt mit settimeout (meiner Alternativlösung die ebenfalls nicht so tut wie ich will - leider).
Umfeld: Funktion die sich selbst aufruft mit settimeout am Ende (die Werte des timeouts in ms sind linkerhalb unten), ein div soll sich damit 450 Pixel weit nach rechts bewegen und das in 3 Pixel-Schritten. Danach soll die Zeit in ms ausgeben werden die die Funktion benötigt hat (rechterhalb unten) um diese 450 pixel zu zählen (150 DDurchläufe).Timeout Benötigte Zeit
1ms 1600ms
2ms 1600ms
5ms 1600ms
10ms 1600ms
11ms 1790ms
12ms 2000ms
15ms 2530ms
20ms 3450ms
40ms 6580msFür alle Zweifler.... von wegen das ist durchaus komplexer Code....bla
(Ohne jemandem zu nahe zu treten wollen)
Diese Funktion wurde mit und auch ohne Aufruf der "getobjectbyid" und auch nur mit dem Hochzählmechanismus getestet.Das Ergebnis ist oben ja deutlich zu sehen :-(
Morgen kommt noch ein Test mit setinterval dran. Poste ich selbstverständlich. Jetzt erstma Gute Nacht.
Achja und wenn jemand nochnicht weis was ich Eigentlich vorhab....
Ich suche händeringend nach einer Möglichkeit in Javascript um Elemente einer Site flüssig von A nach B zu bewegen und das flott, ruckelfrei und ultrasmooth wenn ihr wisst was ich damit meine....Wenn da jemand eine Idee zu hat wäre ich echt dankbar.
Aber bitte kommt mir nicht mit irgendeineinem Framework daher. Ich will das selber Coden(mit hilfe des Forums ;-)). Das muss doch irgendwie Möglich sein..... oder ... oder nicht .... ich beginne daran zu Zweifeln.Till tomorrow
-
Hi,
Timeout Benötigte Zeit
1ms 1600ms
2ms 1600ms
5ms 1600ms
10ms 1600ms
11ms 1790ms
12ms 2000ms
15ms 2530ms
20ms 3450ms
40ms 6580msFür alle Zweifler.... von wegen das ist durchaus komplexer Code....bla
(Ohne jemandem zu nahe zu treten wollen)
Diese Funktion wurde mit und auch ohne Aufruf der "getobjectbyid" und auch nur mit dem Hochzählmechanismus getestet.Ja und, was hast du denn jetzt anderes erwartet?
Der Browser braucht zwischendurch auch noch seine Zeit, um die veraenderte Darstellung zu rendern.
Das Ergebnis ist oben ja deutlich zu sehen :-(
Der Schluss, den du daraus zu ziehen hast, sollte ebenso offensichtlich sein:
Zu kleine Zeitintervalle zu waehlen, ist sinnfrei.
Alles unter 10ms bringt keinerlei weiteren Geschwindigkeitsvorteil.Was zu tun ist, wenn die Animation trotzdem schneller ablaufen sollte, wurde hier im Thread schon in hinreichender Detailtiefe beschrieben.
Ich suche händeringend nach einer Möglichkeit in Javascript um Elemente einer Site flüssig von A nach B zu bewegen und das flott, ruckelfrei und ultrasmooth wenn ihr wisst was ich damit meine....
Definiere "fluessig".
Ich habe schon diverse solche Javascript-Animationen gesehen, alle mit nach meinem Maszstab ausreichender "Fluessigkeit".
MfG ChrisB
-
Moin!
und an der Stelle muss ich gleich sagen das der von mir gepostete Code Müll ist, den setzte ich nicht ein, der war nur zur Visualisierung gedacht!
Du ahnst, wie ernst du genommen wirst, wenn du Problemlösungen zu nichtgenutztem Code wünschst?
Umfeld: Funktion die sich selbst aufruft mit settimeout am Ende (die Werte des timeouts in ms sind linkerhalb unten), ein div soll sich damit 450 Pixel weit nach rechts bewegen und das in 3 Pixel-Schritten. Danach soll die Zeit in ms ausgeben werden die die Funktion benötigt hat (rechterhalb unten) um diese 450 pixel zu zählen (150 DDurchläufe).
Timeout Benötigte Zeit
1ms 1600ms
2ms 1600ms
5ms 1600ms
10ms 1600ms
11ms 1790ms
12ms 2000ms
15ms 2530ms
20ms 3450ms
40ms 6580msWie du siehst, benötigt die Funktion selbst etwa 10 Millisekunden. Bei 150 Durchläufen also 1500 Millisekunden. Und offenbar sind noch 100 Millisekunden zusätzlich verbratene Zeit mit drin.
Wählst du 40 Millisekunden als Zwischenzeit, hast du 40*150 = 6000 Millisekunden Ausführungszeit, plus 580 Millisekunden.
580 ms verhalten sich zu 6000 ms ungefähr so, wie 100 ms zu 1500 ms - das ist eine zeitliche Ungenauigkeit, die vollkommen im Rahmen liegt, etwa 10%.
Es entspricht halt derzeitigem Browserverhalten, siehe http://ejohn.org/blog/analyzing-timer-performance/.
Abgesehen davon ist die benötigte Zeit ja absolut in Ordnung, sie entspricht deinen Vorgaben.
Das Ergebnis ist oben ja deutlich zu sehen :-(
Richtig. Welches Problem siehst du bei dem Ergebnis? Was kritisierst du genau?
Achja und wenn jemand nochnicht weis was ich Eigentlich vorhab....
Ich suche händeringend nach einer Möglichkeit in Javascript um Elemente einer Site flüssig von A nach B zu bewegen und das flott, ruckelfrei und ultrasmooth wenn ihr wisst was ich damit meine....Diese Möglichkeit existiert nicht. Zumindest nicht in existierenden Browsern. Denn die haben mit der zeitlich korrekten Ausführung von Timern, egal ob Timeout oder Interval, so ihre Probleme. Es war bislang auch noch nie wirklich eine Anforderung gewesen, da man Animationen mit Javascript aufgrund der langsamen Darstellung und der langsamen Ausführungsgeschwindigkeit von Javascript und DOM-Operationen eigentlich eher vermieden hat. Erst mit dem Aufkommen der entsprechenden Frameworks (Prototype, jQuery, etc.) und der damit verbundenen browserübergreifenden Animationsmöglichkeit ist der Fokus der Entwicklung von Javascript-Engines plötzlich auch auf deren zeitliches Verhalten gerückt.
Trotzdem hast du auf den finalen Darstellungspart mit Javascript absolut keine Einflußmöglichkeit. Du sagst dem Element lediglich, wo es sich - mit CSS - denn bitteschön befinden soll; wie schnell der Browser es dort hinmalt, liegt außerhalb deines Einflußbereichs.
Wenn da jemand eine Idee zu hat wäre ich echt dankbar.
Aber bitte kommt mir nicht mit irgendeineinem Framework daher. Ich will das selber Coden(mit hilfe des Forums ;-)). Das muss doch irgendwie Möglich sein..... oder ... oder nicht .... ich beginne daran zu Zweifeln.Grundsätzlich hat man immer die Wahl, das Knowhow eines Frameworks einzusetzen, oder sich den ganzen Krams selbst zu erarbeiten - inklusive aller Browserversionsprobleme, die auftreten werden.
- Sven Rautenberg
--
"Love your nation - respect the others." -
Hallo,
Achja und wenn jemand nochnicht weis was ich Eigentlich vorhab....
Ich suche händeringend nach einer Möglichkeit in Javascript um Elemente einer Site flüssig von A nach B zu bewegen und das flott, ruckelfrei und ultrasmooth wenn ihr wisst was ich damit meine....Das gibts schon eine Fertiglösung, nennt sich Adobe Flash, ist aber nicht ganz JavaScript.
Ernsthaft: Das ist das einzige, was zu deinem Anliegen sinnvoll zu sagen ist. Da braucht man nicht lamentieren, weil man die Grenzen der aktuellen Browser nicht überschreiten kann, außer man nimmt etwas anderes als HTML/CSS, z.B. Flash, Canvas, SVG, wasweißich.
Mathias
-
-
-
Aber nun zum Informativsten Beitrag von Sven Rautenberg:
Danke nochmal ;-DAber nochmal zum Prob, du hast geschrieben Zitat:
<---
jedenfalls verglichen mit der Variante, das Funktionsergebnis einmalig in einer Variablen zwischenzuspeichern und jeweils dort wieder abzurufen.
--->Das ist aber leider nicht richtig, auch wenn es theoretisch so sein müßte, ist es aber in der Praxis nicht immer so, dass der Zugriff über eine Variabel schneller ist, als über getElementById()
Dein Porblem ist, dass dir nicht klar ist, das das Bewegen eines Elementes auf einer HTML Seite ein sehr hohen Aufwand bedeutet, 100ms für einen Pixel ist schon schnell.
Struppi.
-
-
Hallo Sven,
getElementById ist beispielsweise eine Funktion, deren Ausführung relativ lange dauert - jedenfalls verglichen mit der Variante, das Funktionsergebnis einmalig in einer Variablen zwischenzuspeichern und jeweils dort wieder abzurufen.
Nur eine kleine Anmerkung: Ich gehe davon aus, dass jede halbwegs kompetente DOM-Implementierung für getElementById() einen internen schnell nachschlagbaren Index führt, so dass das Auffischen einer Element-Referenz nicht viel langsamer ist als das Dereferenzieren einer JS-Objektreferenz.
Tim
-
Nur eine kleine Anmerkung: Ich gehe davon aus, dass jede halbwegs kompetente DOM-Implementierung für getElementById() einen internen schnell nachschlagbaren Index führt, so dass das Auffischen einer Element-Referenz nicht viel langsamer ist als das Dereferenzieren einer JS-Objektreferenz.
So ist es.
Struppi.
-
Hallo,
Nur eine kleine Anmerkung: Ich gehe davon aus, dass jede halbwegs kompetente DOM-Implementierung für getElementById() einen internen schnell nachschlagbaren Index führt, so dass das Auffischen einer Element-Referenz nicht viel langsamer ist als das Dereferenzieren einer JS-Objektreferenz.
Ja, ich staune, wie schnell das geht: In einer Tabelle mit über 1700 Zeilen, kann ich bei jedem Tastendruck in ein Eingabefeld über getElementById() feststellen, ob eine entsprechende Zeile existiert, ohne jede erkennbare Verzögerung :-).
Gruß, Don P
-
-