This article describes how to implement animation using the Java applet API. It describes commonly used techniques and gives a simple example to illustrate each technique.
Basic animation techniques
Many forms of animation are possible in Java. What all of them have in common is that they create some kind of motion on the screen by drawing successive frames at a relatively high speed (usually about 10-20 times per second).
We will start by creating a simple template applet for doing animations and slowly elaborate it until we arrive at a fairly complete applet.
Using a thread
To update the screen multiple times per second, you need to create a new Java thread that contains an animation loop. The animation loop is responsible for keeping track of the current frame and for requesting periodic screen updates. To implement a thread, you must either create a subclass of Thread or adhere to the Runnable interface.
A common mistake is to put the animation loop in the paint() method of an applet. Doing so will have strange side effects because it holds up the main AWT thread, which is in charge of all drawing and event handling.
As an example I have written a small template applet, called Example1Applet, that illustrates the general outline of an animation applet. Example1Applet shows how to create a thread and call the repaint() method at fixed intervals. The number of frames per second is specified by passing in an applet parameter. Here is an example of what you would put in your HTML document:
<applet code=Example1Applet.class width=200 height=200>
<param name=fps value=20>
</applet>
Here is Example1Applet.
Note:
This applet doesnโt actually draw anything on the screen yet. Drawing to the screen is explained later. Note also that the applet destroys its animation thread whenever the user leaves the page (which results in the appletโs <b>stop()</b> method being called). This ensures that the applet wonโt waste CPU time while its page isnโt visible.
Keeping a constant frame rate
In the example above, the applet simply sleeps for a fixed amount of time between frames. This has the drawback that you sometimes wait too long. To get 10 frames per second you should not wait 100 milliseconds between frames, because you lose some time just running the thread.
The following applet, Example2Applet, shows how to keep better time. It simply computes the correct delay between frames by keeping track of the starting time. It computes the estimated required delay between frames based on the current time.
Here is Example2Applet.
Painting each frame
What remains is to paint each frame. In the previous examples, we call <b>repaint()</b> for each frame, which causes the appletโs paint() method to be called. The Example3Applet has a paint() method that draws the number of the current frame to the screen.
Here is Example3Applet in action, followed by a code listing.
Note:
If you specify the frame rate to be very high (say 100 frames per second), the <b>run()</b> method will call <b>repaint()</b> 100 times per second. However, this will not always result in 100 calls to <b>paint()</b> per second because when you issue repaint request too quickly they will be collapsed into a single screen update. This is why we keep track of the current frame number in the <b>run()</b> method rather then in the <b>paint()</b> method.
Generating graphics
Now letโs animate something that is a little harder to draw. The Example4Applet draws a combination of sine waves. For each x coordinate, it draws a short vertical line. All these lines together form a simple graph that changes for each frame. Unfortunately, you will find that this approach causes a lot of flashing. Weโll explain the cause of the flashing and some remedies in the next section.
Here is Example4Applet in action, followed by a code listing.
Avoiding excessive flashing
The flashing you see in Example4Applet has two causes: painting each frame takes too long (due to the amount of computation that is required during the repaint) and the entire background is cleared before <b>paint()</b> is called. While the computation of the next frame is going on, the user is seeing the background of the animation.
This short time between the clearing of the background and the painting of the sine wave is seen as a flash. On some platforms like the PC, the flashing is more obvious then it is on X Windows. The reason is that the X Windows graphics are buffered, which makes the flash a little shorter.
You can reduce flashing greatly using two simple tricks: implementing the <b>update()</b> method and using double buffering (sometimes known as using a backbuffer).
Overriding the update() method
When the AWT receives a repaint request for an applet, it calls the appletโs <b>update()</b> method. By default, the <b>update()</b> method clears the appletโs background and then calls the <b>paint()</b> method. By overriding the <b>update()</b> method to include the drawing code that used to be in the <b>paint()</b> method, we avoid having the appletโs entire area cleared with every repaint.
Now that the background is no longer cleared automatically, we need to do it ourselves in the <b>update()</b> method. We can now erase each vertical line of the graph individually before drawing the new line, eliminating the flashing completely. This effect is shown in Example5Applet.
Here is Example5Applet in action, followed by a code listing.
Note:
Whenever you override the <b>update()</b> method, you still need to implement <b>paint()</b>. This is because the <b>paint()</b> method is called directly by the AWT drawing system whenever โdamageโ occurs to the appletโs drawing area โ for example, when a window obscuring part of the appletโs drawing area is removed from the screen. Your <b>paint()</b> implementation can simply call <b>update()</b>.
Double buffering
Another way of reducing the flashing between frames is to use double buffering. This technique is used in many animation applets.
The general principle is that you create an offscreen image, you draw a frame into the image, and then you slap the entire image onto the screen with one call to <b>drawImage()</b>. The advantage is that most of the drawing is done offscreen. The final painting of the offscreen image onto the screen is usually much more efficient than painting the frame directly to the screen.
The sine wave applet with double buffering is shown in Example6Applet. You will see that the animation is pretty smooth and you donโt need any special tricks when drawing the frame. The only disadvantage is that you have to allocate an offscreen image that is as large as the drawing area. If the drawing area is very large, this may demand quite a lot of memory.
Here is Example6Applet in action, followed by a code listing.
Note:
When you use double buffering, you need to override the <b>update()</b> method, since you donโt want the appletโs background to be cleared before you paint the frame. (You clear the background yourself by drawing to the offscreen image.)
Using images
Now weโll rewrite the <b>paintFrame()</b> method with a method that animates some images. This adds some minor complications to the problem. Images are rather large and they are loaded incrementally. It can take a long time for images to be fully drawn, especially when you are loading them over a slow connection. This is the reason why the <b>drawImage()</b> method takes a fourth argument, an ImageObserver object. The image observer is an object that is notified when more of the image data has arrived. To get the images we use the <b>getImage()</b> method.
Moving an image across the screen
This first image-animating applet, Example7Applet, uses the following two images:
world.gif: car.gif:
The world image is used as the background, and the car image is drawn on top of it twice, creating an animation of two cars racing across the world.
Here is Example7Applet in action, followed by a code listing.
Displaying a sequence of images
Example8Applet shows how to create an animation using separate images for each frame. Here are the 10 frames that are being used:
T1.gif: T2.gif: T3.gif: T4.gif: T5.gif:
T6.gif:
T7.gif:
T8.gif:
T9.gif:
T10.gif:
We are still using double buffering to eliminate flashing. The reason is that each image that we are rendering is partially transparent, and we therefore need to erase each frame before drawing the next. This would cause flashing without double buffering.
Here is Example8Applet in action, followed by a code listing.
Note:
When displaying sequences of images, you have to be careful to align the images correctly. The easiest way is to make sure that the images are all the same size and can be drawn at the same position. If that isnโt the case, your applet will have to draw each frame at a different offset.
Using MediaTracker to avoid incremental display
When a Java program loads an image, it can display the image before the image is completely loaded. The user sees the image being rendered first incompletely, and then incrementally more and more completely as the image is loaded. This incremental display gives the user feedback (improving perceived performance) and lets the program easily perform other tasks while the image is loading.
Where animation is concerned, incremental image display can be useful for background images, but it can be very distracting when used for the animated images. It is therefore sometimes desirable to wait until the entire animation is loaded before displaying it.
You can use Jim Grahamโs MediaTracker class to track the downloading of images, delaying the animation display until the entire set of images is fully downloaded. Example9Applet shows how to use the MediaTracker class to download images for the waving Duke animation.
Here is Example9Applet in action, followed by a code listing.
Adding sound
Itโs easy to add sound to an animation. You can use the <b>getAudioClip()</b> method to get an AudioClip object. Later, you can play the clip either as a continuous loop or as a single sound. Example10Applet shows how to play a continuous background sound as well as a repetitive sound during the animation.
Here is Example10Applet in action, followed by a code listing.
Note:
When playing a continuous sound you must remember to stop it when the user leaves the page (i.e., do it in your appletโs <b>stop()</b> method).
Another note:
Continuous audio can be very annoying. It is a good idea to provide the user with a way to turn off the audio without leaving the page. You can provide a button, or simply turn off the audio when the user clicks in the applet.
Tips for loading images faster
An animation that uses many images will take a long time to download. This is mainly due to the fact that a new HTTP connection is made for every image file, and making a connection can take several seconds even when there is plenty of bandwidth.
In this section, weโll tell you about two image formats your applet can use to make downloading images faster.
Using an image strip
You can improve downloading performance by using a single image containing several frames of animation. You can render a single frame out of the image by using the <b>clipRect()</b> operator. Below is an example of an image strip that is used in the UnderConstruction applet.
The applet creates a drilling effect by not erasing the previous frames. The background is cleared only every so often.
Here is UnderConstruction in action, with a link to its source code.
Inter-frame compression using Flic
If you really want to improve the downloading performance of an animation consisting of multiple frames, then you have to use some form of inter-frame compression.
Animation tools
At this moment (January 1996), few tools are available to help you create Java-powered animations. The best tool that I could find is DimensionXโs The Easy Animator (TEA) (previously known as JAM). It lets you create animations interactively. Weโd like to encourage developers to write more tools for the creating of animations in Java.
If you have a few ready-made images to display, you can use the Animator applet. Animator has many parameters that let you specify continuous sounds, frame-specific sounds, individual frame timing and positions, a startup image, frame ordering, and so on.
You should also check out the Gamelan Animation page to find many applets that use animation.
Conclusion
I hope this article will help applet developers write more and better animation applets. I also hope that better tools will become available soon.


