Building A Great DHTML Chaser - DHTML Lab | 5
DHTML in GreatEqualizer.com, I:
Building A Great DHTML Chaser
We've got a chaser now, but unfortunately, it has some fundamental problems.
The most important thing to realize is that the method paint()
is probably not truly being invoked as fast as callRate specifies.
In reality, callRate is merely the target delay between each call
For instance, simple_chaser.html looks pretty decent on my Win '95 test computer. This is because I've got callRate set to 55, which is the theoretical maximum CPU resolution for that operating system. However, on my development machine - Win 2000 with an 800Mhz processor and 512Mb RAM - the script performs much better with lower callRate settings and higher divisor settings. But this setup looks terrible on every other platform!
What I'm saying is that there's an infinite number of variables that can and will detract from your DHTML's performance. More than just browser version and platform, DHTML is extremely susceptible to other programs competitng for processor cycles. To compound matters, the sheer quantity of these variables makes the situation impossible to program or test for directly.
Let's say we can describe an average animation with the equation:
AnimationLength = FrameRate x NumberOfFrames
In order to account for problems like this, many professional animators take a different strategy than we did with our simple animation function. They make AnimationLength the only known property, and let FrameRate and NumberOfFrames vary. What this means is that on a slow computer, there will be less frames, and on a fast computer there will be more - but no matter what, the animation will always end at the same time.
The following table shows a more detailed example:
|Relative Speed of System||Total Animation Length||Number of Frames||Length of Each Frame|
You can see that the total time for the animation is always the same. It's just that the faster systems are able to execute more frames in that time than the slower ones. What we're looking for, from a programming standpoint, is an algorithm that automatically causes the number of frames to be as great as possible.
Here is that algorithm:
Record the current time, as measured from the computer's clock.
Record the time again and calculate the difference from the time that has elapsed since Step 1.
Take the elapsed time derived from Step 2 and use it as the x-axis input (usually "t") for whatever equation you are using to describe your DHTML animation. Record this number.
If the number calculated in Step 3 is greater than the final position you desire for your animation, Go to Step 7.
Move the object being animated to the number recorded in step 3.
Go to Step 2.
Move the object to the final position desired for the animation.
In step 3, I refer vaguely to an animation "equation." That equation needs to describe the deceleration motion of the chaser, so that we can plot its position for each frame of animation. Acceleration/deceleration is a huge topic, but many people in the DHTML world (Dan Steinman, Peter Belesis, etc) have noted that the sine wave is a particularly elegant way to go about it.
On the next page, I'll show you how a sine wave can be made to describe deceleration for the chaser object we're creating. Although reading it is not absolutely necessary, I recommend it for anybody who really wants to understand what's going on under the hood.
Produced by Aaron Boodman andAll Rights Reserved. Legal Notices.
Revised: Sept 19, 2000