Meinung
Frustrus
- dhtml
Hallo Forum!
Jeder, der sich zum ersten mal mit Dhtml befasst hat, kennt diesen Effekt: Erst ist man himmelhochjauchzend,weil es da so viele tolle Möglichkeiten gibt, Dynamik in eine Webseite zu bringen. Und dann kommt die Ernüchterung: Sobald man ein "setInterval" oder ein "setTimeOut" von weniger als 50 ms einstellt, gehts trotzdem nicht schneller. Um die Dynamik aber doch noch zu steigern, stellt man grössere Sprünge ein, jedoch mit dem Effekt, dass die schöne Sequenz daraufhin ruckelt und unansehnlich (und auch unprofessionell) wirkt. Ich denke, dies ist der Hauptgrund, warum z.B das kommerzielle "Flash" so viel Erfolg hat: Im Prinzip macht es NICHTS, was man nicht auch mit JavaScript realisieren könnte, aber mit dem Unterschied, dass hier schnellere Zeiten als 50 ms möglich sind, und deshalb alles flüssiger aussieht. Nach tagelangem Herumprobieren geb ichs jetzt auf, einen Weg zu finden, wie man in Javascript schnellere Zeitsprünge zusammentrickst als diese lahmen 50 ms.
Dazu mal ein kleiner "Benchmarck":
<script language="JavaScript">
<!--
for (i=0; i<500; i++) {
jetzt = new Date();
document.write(jetzt.getTime()+'<br>\n');
}
//-->
</script>
Unschwer zu erkennen, dass die For-Schleife in jedem Durchgang die vergangenen Millisekunden seit 1.1.70 ermittelt. Das Ergebnis: Anstatt schön brav JEDE Millisekunde anzuzeigen (947580285410, 947580285411 ,947580285412, usw.), sieht man, dass Schrittweiten von nur 50 bzw. 60 ms ermittelt werden (947580285410, 947580285460, 947580285520, usw.. Und das ist lahm!
Gibt über dieses Forum keinen Weg, eine Art "Petition" mit "Unterschriften" an das W3C zu schicken, dieses Manko abzustellen? Damit wir auch ohne Flash- oder Java-Nutzung flüssige Dynamik auf die Webseite bringen können? Oder weiss jemand, welche tiefen Hintergründe hinter diesem lahmen "setInterval" stehen? Andere Programme können dies schliesslich auch, warum nicht Javascript?
gez.
Ein Frustrierter
ganz einfach:
würde man die schleife unkontrolliert an den prozessor schicken, würde der rechner "stehen", du kennst das: maus ruckelt, nichts geht mehr. deshalb hat man wahrscheinlich die javascripts auf eine niedrige priorität gesetzt, damit kann eine seite nicht absichtlich die browser tot machen
ganz einfach:
würde man die schleife unkontrolliert an den prozessor schicken, würde der rechner "stehen", du kennst das: maus ruckelt, nichts geht mehr. deshalb hat man wahrscheinlich die javascripts auf eine niedrige priorität gesetzt, damit kann eine seite nicht absichtlich die browser tot machen
Hallo Gerhard!
Eben deshalb, damit man keine Schleifen braucht, gibt es ja "setInterval" bzw. setTimeout".
Java beweist, dass es geht, auch ohne den Browser zu belasten. Beispiele dafür gibt es zur genüge.
Frustrus
Eben deshalb, damit man keine Schleifen braucht, gibt es ja "setInterval" bzw. setTimeout".
Java beweist, dass es geht, auch ohne den Browser zu belasten. Beispiele dafür gibt es zur genüge.Frustrus
hallo frustrus
bei settimeout unter einem bestimmten kritischen wert würde die message-queue mehr messages erhalten als sie abarbeiten kann. über kurz oder lang würde die maschine nicht mehr genug speicher haben. ich denke das hat seinen sinn.
Java hingegen läuft in einer virtuelle maschine, in einer eigenene "sandbox", dort kann sie machen was sie will, weil sämtliche aktionen von außen steuerbar sind.
mfg Gerhard
Oder weiss jemand, welche tiefen Hintergründe hinter diesem lahmen "setInterval" stehen? Andere Programme können dies schliesslich auch, warum nicht Javascript?
Hallo,
ich rat mal einfach nur so welche gründe das haben kann:
1.)kein binär code, muß wie bei zb. PERL, PHP und ASP zu laufzeit compiliert werden
2.)die javascript-"engine" hängt an der css-"engine" (mit abgeschaltetem javascript kein css :( )
3.)Die Prozessorlast wäre zu groß (die browser sollen ja auch noch auf einem mmhh P90 laufen)und darum wurde der kompromiss mit den 50ms eingegangen
4.)der vorteil von Flash liegt in folgenden punkten:
a)das ganze handling für das movie wird vom plugin übernommen welches natürlich binär ist, genau so wie das movie
b)beim movie müssen keine schwierigen und umfangreiche fehlerkorrekturen eingefügt werden, das erledigt daß programm mit dem das movie erstellt wurde (flash bzw director)
Korigiert mich wenn ich schei?? verzapfe :-)
lg
Ludwig
Im Prinzip macht es NICHTS, was man nicht auch mit JavaScript realisieren könnte, aber mit dem Unterschied, dass hier schnellere Zeiten als 50 ms möglich sind, und deshalb alles flüssiger aussieht.
Da kann ich dir nicht ganz recht geben:
man kann mit Javascript bei weitem nicht das realisieren, was mit flash möglich ist (in einem ähnlichen Aufwand, und einem Ergebnis, das ähnlich kleine Dateien liefert)
ich hab noch kaum ein (größeres) Flash gesehen, das (auf meinem P166) nicht ruckelt. Vielleicht stelle ich deshalb nicht zu große Anforderungen?
Zu den 50ms: Ich habe durchaus den Eindruck, daß setTimeouts mit Zeitangaben kleiner als 50ms meine Scripts schneller werden lassen, aber daß die Geschwindigkeit im Endeffekt sehr stark von der Leistung des Clientrechners abhängt.
mfG
BRAND
Zu den 50ms: Ich habe durchaus den Eindruck, daß setTimeouts mit Zeitangaben kleiner als 50ms meine Scripts schneller werden lassen, aber daß die Geschwindigkeit im Endeffekt sehr stark von der Leistung des Clientrechners abhängt.
Hallo Brandt!
Geschwindigkeiten von mehr als 50 ms sind bei Javascript nicht möglich. Es gibt höchstens den merkwürdigen Effekt, dass bei auf unter 50ms eingestellter Zeit die Grafiken schneller laufen wenn
a.) Du sie anklickst und dabei ziehst
b.) Du mit der Maus über die Buttonleiste hin- und herfährst, oder im Bereich Statusleiste. Probier das mal aus!
Mfg
Frustrus
Hi!
Jetzt habe ich dein script mal laufen lassen. Wenn ich die Ausgabe richtig interpretiere komme ich auf kleiner Werte als 50ms.
Hier ein Auszug aus dem Ergebnis(deines scripts):
947669310860
947669310860
947669310860
947669310860
947669310860
947669310860
947669310860
947669310860
947669310860
947669310870
947669310870
947669310870
947669310870
947669310870
947669310870
947669310870
947669310870
947669310870
947669310880
947669310880
947669310880
947669310880
947669310880
947669310880
947669310880
947669310880
947669310880
947669310880
947669310880
947669310890
...woraus schließt du jetzt, auf eine minimale setTimeout-zeit von 50ms??
weiters zeigt mir bei folgendem script das alert(...) als kleinsten Zeitunterschied 10ms.
<script language="JavaScript">
<!--
function start()
{ jetzt = new Date();
a1=jetzt.getTime();
setTimeout('func2()', dt);
}
function func2()
{ jetzt2 = new Date();
a2=jetzt2.getTime();
alert(a2-a1);
}
//-->
</script>
</HEAD>
<BODY onLoad="start()">
Ergebnisse:
dt(ms) a2-a1 (ms)
------------
60 60
55 60
50 50
45 50
40 40
35 40
30 30
25 30
20 20
15 20
12 20
10 80%...10, 20%...20
8 - " -
(getestet mit IE5.0, NT4.0, Pentium166)
Bei mir sieht das irgendwie so aus, daß nichts kleineres als 10ms aufgelöst werden kann. Obwohl natürlich pro 10 ms einige Befehle abgearbeitet werden.
mfG
BRAND
#(getestet mit IE5.0, NT4.0, Pentium166)
#Bei mir sieht das irgendwie so aus, daß nichts #kleineres als 10ms aufgelöst werden kann. Obwohl #natürlich pro 10 ms einige Befehle abgearbeitet werden.
Hallo Brandt!
Durch Dein Posting ist mir bewusst geworden, wie sehr alles von der Plattform abhängig ist. Ich muss gestehen, dass ich an den Plattform-Aspekt bisher noch gar nicht gedacht hatte, obwohl es am naheliegendsten war.
Ich hab Dein Skript mal auf Win 98 laufen lassen. Die Ergebnisse schwankten, je nach dem Betätigungsmoment des Reload-Buttons.
IE 5.0, auf win 98:
dt(ms) a2 - a1 (ms)
--------------------------------------------------------
60 60, 110, 170, 50
30 0, 50, 60, 110
10 0, 60, 50
Der NN zeigte genau die gleichen Werte. Ebenso SO 5.1.
Opera auf Win 98:
dt(ms) a2 - a1 (ms)
--------------------------------------------------------
60 0, 0, 0,1032, 0, 0,1032
30 0,1033, 0, 0, 0, 0
________________________________________________________________
Dann hab ich Dein Skript mal unter Linux laufen lassen:
NN 4.7:
dt(ms) a2 - a1 (ms)
--------------------------------------------------------
60 68, 70, 75, 69
30 36, 29, 36, 27
10 14, 11, 25, 18
1 17, 9, 16, 7
Super Werte also. Und SO 5.1 unter Linux lag genauso gut wie der NN unter Linux.
Falls es Dich interessiert, hier mal ein Auszug der Werte meines (im Vergleich zu Deinem) bescheidnen Skripts unter Linux:
947684687710
947684687711
947684687712
947684687713
947684687714
947684687716
947684687717
947684687718
947684687719
947684687720
947684687722
947684687723
947684687724
947684687725
947684687726
947684687727
947684687728
947684687729
947684687730
Sieht also schon ganz anders aus. Die Lahmheit der "setTimeouts" und "setIntervals" hat also nicht so sehr mit dem Browser zu tun, sondern viel mehr mit dem Betriebssystem. Obwohl ich Linux auf dem Rechner habe, erstelle meine die Html-Seiten unter Windows, weil ich dann sofort mit IE + NN kontrollieren kann und die meisten ja win98 nutzen. Deshalb ist mir die Plattformabhängikkeit bisher nicht aufgefallen. Ich kann nur Hoffen, dass andere aus diesen und anderen Erfahrungen lernen, und dieses sch... windoof von ihren Rechnern schmeissen. Ich will ja keine Reklame machen, aber das neue SuSe-Linux 6.3 ist so gut, dass es M$ bei weitem in den Schatten stellt. Hoffentlich wird es sich durchsetzen.
Mfg
Frustrus