A word of warning in the beginning, this might get lengthy...
I'd be really interested to see this scheme in action, since I also can't
quite see the benefit of this scheme using the threads/timers based
synchronization and/or to gain performance boost. It's not that I don't
believe in that, but I just don't understand it...
I've done couple of tests on timerbased threads also, here's a little
something:
The timer based threads are not really threads, since they cannot execute at
the same time (even virtually). This means that if you burden your other
thread, the other also suffers in the sense that the timer looses its
accuracy. Depending how you wan't to synchronize your threads, trusting the
timerevents can be quite dangerous. If a smooth time dependent animation is
wanted, I would propably snap to some initial date value instead of trusting
the settimeout/setinterval.
An interesting point that I noticed was that using the setTimeout seems to
be much more reliable than using the setInterval. (I don't deny the
possibility of bugs in my test code, but I of course doubt it :)
Anyway, I made a test which has two threads, the other one just reporting
how long it was since it was executed last time, and the other, besides
doing the same as the first thread, spending each round one more
millisecond. (Tests run in NT4 sp6, ie5.5 and ns4.72)
Here is a test run based on setTimeout. Both threads were to run once in 20
milliseconds, LIGHT being the light one, and HEAVY being the burdened one
:). The value after the name is the round (ie milliseconds spent by HEAVY)
and final value is milliseconds from last round. Sorry about the lengthy
output, but here it comes anyway ;) :
LIGHT: 1: 20
HEAVY: 1: 20
LIGHT: 2: 20
HEAVY: 2: 20
LIGHT: 3: 20
HEAVY: 3: 20
LIGHT: 4: 20
HEAVY: 4: 20
LIGHT: 5: 20
HEAVY: 5: 20
LIGHT: 6: 20
HEAVY: 6: 20
LIGHT: 7: 20
HEAVY: 7: 20
LIGHT: 8: 20
HEAVY: 8: 20
LIGHT: 9: 20
HEAVY: 9: 20
LIGHT: 10: 20
HEAVY: 10: 20
LIGHT: 11: 20
HEAVY: 11: 20
LIGHT: 12: 30 <-- Hello World :)
HEAVY: 12: 20
LIGHT: 13: 20
HEAVY: 13: 20
LIGHT: 14: 20
HEAVY: 14: 20
LIGHT: 15: 20
HEAVY: 15: 20
LIGHT: 16: 20
HEAVY: 16: 20
LIGHT: 17: 20
HEAVY: 17: 20
LIGHT: 18: 20
HEAVY: 18: 20
LIGHT: 19: 20
HEAVY: 19: 20
LIGHT: 20: 20
HEAVY: 20: 20
LIGHT: 21: 20
HEAVY: 21: 20
LIGHT: 22: 30 <-- Delayed by 10ms
HEAVY: 22: 30
LIGHT: 23: 30
HEAVY: 23: 30
LIGHT: 24: 30
HEAVY: 24: 30
LIGHT: 25: 30
HEAVY: 25: 30
LIGHT: 26: 30
HEAVY: 26: 30
LIGHT: 27: 31
HEAVY: 27: 31
LIGHT: 28: 30
HEAVY: 28: 30
LIGHT: 29: 30
HEAVY: 29: 30
LIGHT: 30: 30
HEAVY: 30: 30
LIGHT: 31: 30
HEAVY: 31: 30
LIGHT: 32: 40 <-- Again delayed
HEAVY: 32: 40
LIGHT: 33: 40
HEAVY: 33: 40
LIGHT: 34: 40
HEAVY: 34: 40
LIGHT: 35: 40
HEAVY: 35: 40
LIGHT: 36: 40
HEAVY: 36: 40
LIGHT: 37: 40
HEAVY: 37: 40
LIGHT: 38: 40
HEAVY: 38: 40
LIGHT: 39: 40
HEAVY: 39: 40
LIGHT: 40: 40
HEAVY: 40: 40
LIGHT: 41: 40
HEAVY: 41: 40
LIGHT: 42: 50
HEAVY: 42: 50
The output shows us several things. First of all, The threads are not
executed stably in every 20 milliseconds even w/o too much processing in the
threads (sometimes 30 millis). Secondly, when the processing time in HEAVY
goes over 20 milliseconds, both of the threads are delayed. Not just the
HEAVY one. There seems to be a 10ms accuracy with the settimeout, ie if the
browser is not idle, the timeout is extended by 10ms (At least with this
assembly, probably property of OS) Other than those, I think the threads
worked pretty well.
But as I said, it depends how you wan't to make the synchronization. In any
case, I would use some property accessible to every thread, controlled by
the synchronization target (time, player coords, etc), not trusting the
timer to launch loyally every time you want.
BTW, The shortest time the timeout could run was 10ms (Because the 10ms
delay explained before), which is much more than the 40hz. So is my OS just
so good, or is it after all a rendering dependant problem (No rendering done
during this test)? I can't really run this test w/ w9x, because I don't have
one. :)
--
Tuomas Huhtanen
_______________________________________________
Dynapi-Help mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-help
