Very interesting test, David. I'll be playing around with it a bit more
with time. On Win2k it's fairly boring, since the minimum timeslice is
10 ms all the time and it doesn't vary from that. I'm curious to see the
results of the test under Win98.
I've been doing some experimentation with animations myself and have
come up with an interesting conclusion regarding IE5/Win2k. Basically,
the timing system of the browser only seems to work in 10 ms steps,
which would explain why that's the minimum timeslice.
For example, when I run the code below to alert the minimum time between
two Dates:
javascript:var date=new Date();while(!(date - new Date()));alert(new
Date() - date)
I get 10, i.e. it's impossible to get smaller time differences than 10
ms on IE5/Win2k. So if a setTimeout "misses" the timeslice it was
supposed to be executed on due to the processor being busy, it will be
pushed forwards to execute after another 10 ms.
The reason you get 'jumpy' animations is that the animation steps take
varying amount of time(slices) to execute, but the animation /motion/ is
designed for a constant amount of time(slices) to execute. If, for
example, you have a circular animation, and halfways through the circle
it takes twice as long to execute each animation step, the animation
will appear to move twice as slow. Or, worse, imagine a circular
animation where the time it takes to execute each animation step varies
over the course of the animation - it will look 'jumpy', since the speed
of the motion differs throughout the motion.
The most simple way to amend this is to make your animation aware of the
fact that the time between animation steps might vary, and program it so
that it makes each step of the animation vary in "size" according to the
time between this step and the last step. Simple example:
myLayer = new DynLayer(null, 100, 100, 100, 100, 'red')
DynAPI.document.addChild(myLayer)
myThread = new Thread(myLayer)
myThread.run = function()
{
var oldDate = this.date
this.date = new Date()
if (oldDate)
{
var increment = (this.date - oldDate)/10 + this.leftover
this.getDynLayer().moveBy(Math.floor(increment), 0)
this.leftover = increment - Math.floor(increment)
}
if (this.getDynLayer().getX() > 300)
this.stop()
}
myThread.leftover = 0
myThread.sleep(10)
myThread.start()
In this example, the total of the animation would take an equal amount
of time to run from start to finish, regardless of how small or big the
delay is between the individual animation steps. This makes the overall
motion of the animation appear correct, whereas it might get "choppier"
on "slower" systems. For example, if the animation was to make the layer
go around in a circle, the circle motion would look correct on a slower
system or when the animation steps temporarilly took longer to execute,
the tradeoff being that it won't look as smooth. But that's always the
tradeoff when it comes to animations. I tend to prefer making my
animations in this way, since it allows your animation to be as smooth
as is possible on the system it's run on, while always having the
correct motion regardless of performance.
Hope this helps anyone. Comments welcome, of course.
Cheers,
Daniel
David Cushman wrote:
>
> Greetings all,
> I got the animation timing example posted.
> In normal mode, the example uses slideTo and the first
> two values in the form. Nothing else runs during the
> animation, and it uses the standard code. You may
> want to run it the first time with the default
> settings and then hit the "Use Delay" button. This
> adjusts the calculation to reflect the amount of time
> your system is taking to process the code and update
> the screen.
>
> If the multithread is selected, it uses a setTimeout
> in the pathanim run code with a setting of 1 (defaults
> to minimum system timeslice).
>
> Results so far show that it just about reduces the
> speed by 2 (note that the calculations do not reflect
> the use of multithread, so compare the predicted run
> time against the actual). Compare the smoothness of
> the normal animation and the multithread version.
> (withholding my opinions of the results for now).
> Let me know what you think.
> Also, is anyone else interested in this?
> Comments?
>
> Animation Timing example:
> http://www.merlinsworld.net/dynapi_ri_dcexamples/timing01.shtml
>
> Cheers,
> Dave C. "You Changed What?!?"
>
> __________________________________________________
> Do You Yahoo!?
> Get email at your own domain with Yahoo! Mail.
> http://personal.mail.yahoo.com/
>
> _______________________________________________
> Dynapi-Dev mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
--
Daniel Aborg <[EMAIL PROTECTED]>
T: 0207 445 447 M: 07720 29 44 40
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
