This is an interesting approach, although it's difficult to see the effect
on such a simple animation, on a fast machine, your logic seems right.
Maybe the slideTo() code could be altered to contain this principle.
Maybe it needs a kind of floor, so the effect only kicks in at larger timing
delays, to prevent the slight degrading of the animation on a faster
machine.
Maybe the changes should be more gradual, a compromise between exact timing
and jumpy playback.
I get the impression that we should be setting our timing with incrediments
of 55ms, so all machines are brought to the speed (sic) of win98/IE, is this
right?
You made a fine example of a custom thread object while you where at it,
taught me a thing or two. :o)
I'll put that up as an example later.
Cheers,
Richard Bennett
To David: Yes, applying it to a timeline seems a good idea too.
BTW what's "Hello I\'m a little beige layer who\'s going to get clipped!"
doing in the source code of a timing test ?? ;o)
[EMAIL PROTECTED]
www.richardinfo.com
(Everything running on, and ported to the 19/12/2000 snapshot of DynAPI2)
Find the DynAPI faq here:
http://sourceforge.net/docman/display_doc.php?docid=656&group_id=5757
Browse the mailinglist here:
http://www.mail-archive.com/index.php3?hunt=dynapi
----- Original Message -----
From: "Daniel Aborg" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, March 02, 2001 8:41 PM
Subject: Re: [Dynapi-Dev] Animation Timing Example w Multithread
> 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
>
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
