nicht angemeldet
Hallo Philipp,
ich habe die Befürchtung, das dein Wissen um Betriebssystem-Interna in einzelnen Punkten noch bei DOS & Co stahengeblieben ist. Soll kein Vorwurf sein, sorry, ich mein ja nur... ;)
Zuviele andere Faktoren beeinflussen das Experiment (nicht zuletzt
die "Ungenauigkeit" der Systemuhr von PC's, welche nur in 1/18.2
Sekunden Intervallen tickt, da dies intern seit anbeginn so war)...
Wie gesagt, damals unter DOS war das noch so. Allerdings konnte man auch unter DOS schon die Echtzeituhr mitbenutzen, die kann sehr präzise periodische IRQs bis 1024/s generieren. Außerdem kann man im Real-Mode auch den Timer-Baustein abfragen. Der bietet einen Zähler, der um den Faktor 2^16=65536 genauer ist als die DOS-Systemuhr. Tatsächlich programmiert DOS diesen Timerbaustein so, dass er nach jedem kompletten Durchlauf seines 16bit-Zählers einen IRQ auslöst.
Windows 95 hat schließlich eine Systemuhr, die in Millisekunden läuft, und die NT-basierten Systeme (NT selbst, XP, 2k) lösen sogar auf 1/10ms auf.
Das bedeutet natürlich nicht zwangsweise, dass ein Programmierer Zeitabläufe im Millisekundenbereich _realisieren_ kann, dafür spielen zu viele andere Faktoren mit hinein. Aber für die reine _Zeitmessung_ kann man sich erfahrungsgemäß auf die Systemuhr von Windows in etwa auf Millisekunden genau verlassen.
Die Zeitfunktionen von JS gehen ja auch bis auf Millisekunden, und da diese Funktionen von der Systemuhr des Betriebssystems abhängen, darf man hier selbst unter Windows eine bessere Genauigkeit als die legendären 1/18s annehmen. Ein "setTimeout()" kann die angegebene Zeit zwar nicht genau garantieren (siehe oben), aber ein "new Date()" gibt eine für den Aufrufzeitpunkt auf Millisekunden genaue Uhrzeit zurück.
Meine Meinung: Der resize funktioniert für beide Umsetzungen schnell
genug um sich darum keinen Kopf zu machen.
Da stimme ich allerdings vollkommen zu. :)
Herzliche Grüße aus Backnang,
Martin