* Pascal Bestebroer
> anything you can share already ?
>
> logics would be fine...
> ...code would be great :)
code will come. :)
> although I think that the main problem is not the speed of the interrupt
> but more the speed of browser-rendering.
I've only done performance-testing with a single layer, to identify
the timeout problems. of course browsers are not optimized for
animation speed, and therefore one would find some obstacles. but in
my opinion it's much easier to hit your head against one of those if
you have access to a ~40Hz timer, instead of having to hit your head
against that ~18Hz timer.
going multithreading has, as far as I've been able to tell from using
it for a couple of applications, seemed like the way to go. but you
can't simply spawn two setInterval() threads (one using setTimeout()
to fork out), because they won't sync. therefore the solution is as
follows:
1: test setInterval() delay to see if we need the 2nd thread
(Macs, Linux & NT/2k don't need it, as I mentioned earlier)
if the answer to #1 is "yes, we need a 2nd thread", use a
setInterval() delay of 50ms.
2: spawn two threads, one delayed 25ms from the other.
3: gather some data as the timer ticks
these data are used by a 3rd thread that'll check whether the 2nd
thread is fitted in between the ticks of the 1st thread. if it's not
it computes a new value to be used in a setTimeout() call, kills the
2nd thread, and then spawns it off again.
once the 2nd thread is in sync with the 1st the 3rd thread is killed.
given the fact that it rains in Oslo today I'll see if I can come up
with some code for everyone to have a look at.
Morten!
--
"...a liquid which was almost, but not quite, entirely unlike tea."
My opinions are not necessarily those of my provider,
not necessarily mine, and probably not necessary.
_______________________________________________
Dynapi-Help mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-help
