Section 7.6
Timers, Animation, and Threads
JAVA IS A MULTI-THREADED LANGUAGE, which means that
several different things can be going on, in parallel. A thread
is the basic unit of program execution. A thread executes a sequence of instructions,
one after the other. When the system executes a stand-alone program, it creates a thread.
(Threads are usually called processes in this context, but
the differences are not important here.)
The commands of the program are executed sequentially, from beginning to end, by this
thread. The thread "dies" when the program ends. In a typical computer system,
many threads can exist at the same time. At a given time, only one thread can
actually be running, since the computer's Central Processing Unit (CPU) can
only do one thing at a time. (An exception to this is a multi-processing computer,
which has several CPUs. At a given time, every CPU can be executing a different thread.)
However, the computer uses time sharing to give the
illusion that several threads are being executed at the same time, "in parallel."
Time sharing means that the CPU executes one thread for a while,
then switches to another thread, then to another..., and then back to the first thread --
typically about 100 times per second.
As far as users are concerned, the threads might as well be running at the same time.
To say that Java is a multi-threaded language means that a Java program can create
one or more threads which will then run in parallel with the program. This is a fundamental,
built-in part of the language, not an option or add-on like it is in some languages.
Still, programming with threads can be tricky, and should be avoided unless it is really
necessary. Ideally, even then, you can avoid using threads directly by using well-tested
classes and libraries that someone has written for you.
Animation In Swing
One of the places where threads are used in GUI programming is to do animation.
An animation is just a sequence of still images displayed on the screen one
after the other. If the images are displayed quickly enough and if the changes from
one image to the next are small enough, then the viewer will perceive continuous motion.
To program an animation, you need some way of displaying a sequence of images.
A GUI program already has at least one thread, an event-handling
thread, which detects actions taken by the user and calls appropriate subroutines
in the program to handle each event. An animation, however, is not driven by user actions.
It is something that happens by itself, as an independent process. In Java, the most
natural way to accomplish this is to create a separate thread to run the animation.
Before the introduction of the Swing GUI, a Java programmer would have to deal with
this thread directly. This made animation much more complicated than it should
have been. The good news in Swing is that it is no longer necessary to program
directly with threads in order to do simple animations. The neat idea in Swing
is to integrate animation with event-handling, so that you can program animations
using the same techniques that are used for the rest of the program.
In Swing, an animation can be programmed using an object belonging to the
class javax.swing.Timer. A Timer object can generate a sequence
of events on its own, without any action on the part of the user. To program
an animation, all your program has to do is create a Timer and
respond to each event from the timer by displaying another frame in the animation.
Behind the scenes, the Timer runs a separate thread which is responsible for
generating the events, but you never need to deal with the thread directly.
The events generated by a Timer are of type ActionEvent.
The constructor for a Timer specifies two things: The amount of time
between events and an ActionListener that will be notified
of each event:
Timer(int delayTime, ActionListener listener)
The listener should be programmed to respond to events from
the Timer in its actionPerformed() method.
The delay time between events is specified in milliseconds (where
one second equals 1000 milliseconds). The actual delay time between
two events can be longer than the requested delay time, depending on
how long it takes to process the events and how busy the computer is
with other things. In a typical animation, somewhere between ten and
thirty frames should be displayed every second. These rates correspond
to delay times between 100 and 33.
A Timer does not start running automatically when it is
created. To make it run, you must call its start() method.
A timer also has a stop() method, which you can call to
make it stop generating events. If you have stopped a timer and
want to start it up again, you can call its restart() method.
(The start() method should be called only once.) None of
these methods have parameters.
Let's look at an example. In the following applet, you can start
an animation running by clicking the "Start" button. When you do this,
the text on the button changes to "Stop", and you can stop the animation
by clicking the button again. This is yet another applet that says
"Hello World." The animation simply cycles the color
of the message through all possible hues:
Here is part of the source code for this applet, omitting the
definition of the nested class that defines the drawing surface:
public class HelloWorldSpectrum extends JApplet {
Display display; // A JPanel belonging to a nested "Display"
// class; used for displaying "Hello World."
// It defines a method "setColor(Color)" for
// setting the color of the displayed message.
JButton startStopButton; // The button that will be used to
// start and stop the animation.
Timer timer; // The timer that drives the animation. A timer
// is started when the user starts the animation.
// Each time an ActionEvent is received from the
// timer, the color of the message will change.
// The value of this variable is null when the
// animation is not in progress.
int colorIndex; // This is be a number between 0 and 100 that
// will be used to determine the color. It will
// increase by 1 each time a timer event is
// processed.
public void init() {
// This is called by the system to initialize the applet.
// It adds a button to the "south" position in the applet's
// content pane, and it adds a display panel to the "center"
// position so that it will fill the rest of the content pane.
display = new Display();
// The component that displays "Hello World".
getContentPane().add(display, BorderLayout.CENTER);
// Adds the display panel to the CENTER position of the
// JApplet's content pane.
JPanel buttonBar = new JPanel();
// This panel will hold the button and appears
// at the bottom of the applet.
buttonBar.setBackground(Color.gray);
getContentPane().add(buttonBar, BorderLayout.SOUTH);
startStopButton = new JButton("Start");
buttonBar.add(startStopButton);
startStopButton.addActionListener( new ActionListener() {
// The action listener that responds to the
// button starts or stops the animation. It
// checks the value of timer to find out which
// to do. Timer is non-null when the animation
// is running, so if timer is null, the
// animation needs to be started.
public void actionPerformed(ActionEvent evt) {
if (timer == null)
startAnimation();
else
stopAnimation();
}
});
} // end init()
ActionListener timerListener = new ActionListener() {
// Define an action listener to respond to events
// from the timer. When an event is received, the
// color of the display is changed.
public void actionPerformed(ActionEvent evt) {
colorIndex++; // A number between 0 and 100.
if (colorIndex > 100)
colorIndex = 0;
float hue = colorIndex / 100.0F; // Between 0.0F and 1.0F.
display.setColor( Color.getHSBColor(hue,1,1) );
}
};
void startAnimation() {
// Start the animation, unless it is already running.
// We can check if it is running since the value of
// timer is non-null when the animation is running.
// (It should be impossible for this to be called
// when an animation is already running... but it
// doesn't hurt to check!)
if (timer == null) {
// Start the animation by creating a Timer that
// will fire an event every 50 milliseconds, and
// will send those events to timerListener.
timer = new Timer(50, timerListener);
timer.start(); // Make the time start running.
startStopButton.setText("Stop");
}
}
void stopAnimation() {
// Stop the animation by stopping the timer, unless the
// animation is not running.
if (timer != null) {
timer.stop(); // Stop the timer.
timer = null; // Set timer variable to null, so that we
// can tell that the animation isn't running.
startStopButton.setText("Start");
}
}
public void stop() {
// The stop() method of an applet is called by the system
// when the applet is about to be stopped, either temporarily
// or permanently. We don't want a timer running while
// the applet is stopped, so stop the animation. (It's
// harmless to call stopAnimation() if the animation is not
// running.)
stopAnimation();
}
.
.
.
This applet responds to ActionEvents from two sources:
the button and the timer that drives the animation. I decided to use
a different ActionListener object for each source. Each
listener object is defined by an anonymous nested class. (It would, of
course, be possible to use a single object, such as the applet itself,
as a listener, and to determine the source of an event by calling
evt.getSource(). However, Java programmers tend to be fond
of anonymous classes.)
The applet defines methods startAnimation() and stopAnimation(),
which are called when the user clicks the button. Each time the user clicks "Start",
a new timer is created and started:
timer = new Timer(50,timerListener);
timer.start();
Remember that without timer.start(), the timer won't do anything at all.
The constructor specifies a delay time of 50 milliseconds, so there should
be about 20 action events from the timer every second. The second parameter is
an ActionListener object. The timer events will be processed by
calling the actionPerformed() method of this object. The stopAnimation()
method calls timer.stop(), which ends the flow of events from the timer.
The startAnimation() and stopAnimation() methods also change the
text on the button, so that it reads "Stop" when the animation is running and
"Start" when it is not running.
The actionPerformed() method in timerListener responds to a
timer event by setting the color of the display. The color is computed from
a number, colorIndex that is changed for each frame. (The color is
specified as an "HSB" color. See Section 6.3
for information on the HSB color system.)
JApplet's start() and stop() Methods
There is one other method in the HelloWorldSpectrum
class that needs some explanation: the stop() method.
Every applet has several methods that are meant to be called
by the system at various times in the applet's life cycle.
We have already seen that init() is called when the
applet is first created, before it appears on the screen.
Another method, destroy() is called just before the
applet is destroyed, to give it a chance to clean things up.
Two other applet methods, start() and stop(),
are called by the system between init() and destroy()
The start() method is always called by the system just
after init(), and stop() is always called
just before destroy(). However, start()
and stop() can also be called at other times. The reason
is that an applet is not necessarily active for the whole time
that it exists.
Suppose that you are viewing a Web page that contains an applet,
and suppose you follow a link to another page. The applet still exists.
It will be there if you hit your browser's Back button to return to the
page that contains the applet. However, the page containing the applet
is not visible, so the user can't see the applet or interact with it.
The applet will not receive any events from the user, and since it is
not visible, it will not be asked to paint itself. The system calls
the applet's stop() method when user leaves the page that
contains the applet. The system will call the applet's start()
method if the user returns to that page. This lets the applet keep
track of when it is active and when it is inactive. It might want
to do this so that it can avoid using system resources when it is
inactive.
In particular, an applet should probably not leave a timer running
when it is inactive. The HelloWorldSpectrum applet defines
the stop() method to call stopAnimation(), which, in
turn, will stop the timer if it is running. When the
applet is about to become inactive, the system will call stop(),
and the animation -- if it was running -- will be stopped.
You can try it, if you are reading this page in a Web browser:
Start the animation running in the above applet,
go to a different page, and then come back to this page. You should
see that the animation has been stopped.
The animation in the HelloWorldSpectrum applet is started
and stopped under the control of the user. In many cases, we want
an animation to run for the entire time that an applet is active.
In that case, the animation can be started in the applet's start()
method and stopped in the applet's stop() method. It would also
be possible to start the animation in the init() method and
stop it in the destroy() method, but that would leave the
animation running, uselessly, while the applet is inactive. In the
following example, a message is scrolled across the page. It uses
a timer which churns out events for the whole time the applet is active:
You can find the source code in the file
ScrollingHelloWorld.java,
but the relevant part here is the start() and stop()
methods:
public void start() {
// Called when the applet is being started or restarted.
// Create a new timer, or restart the existing timer.
if (timer == null) {
// This method is being called for the first time,
// since the timer does not yet exist.
timer = new Timer(300, this); // (Applet listens for events.)
timer.start();
}
else {
timer.restart();
}
}
public void stop() {
// Called when the applet is about to be stopped.
// Stop the timer.
timer.stop();
}
These methods can be called several times during the lifetime
of an applet. The first time start() is called, it creates
and starts a timer. If start() is called again, the
timer already exists, and the existing timer is simply restarted.
Other Useful Timer Methods
Although timers are most often used to generate a sequence of
events, a timer can also be configured to generate a single event,
after a specified amount of time. In this case, the timer is
being used as an alarm which will signal the program after a
specified amount of time has passed. To use a Timer
object in this way, call setRepeats(false) after
constructing it. For example:
Timer alarm = new Timer(5000, listener);
alarm.setRepeats(false);
alarm.start();
The timer will send one action event to the listener five seconds
(5000 milliseconds) after it is started. You can cancel the alarm
before it goes off by calling its stop() method.
Here's one final way to control the timing of events:
When you start a repeating timer, the time until the first event
is the same as the time between events. Sometimes, it would be
convenient to have a longer or shorter delay before the first event.
If you start a timer in the init() method of an applet,
for example, you might want to give the applet some time to appear
on the screen before receiving any events from the timer. You can set a separate
delay for the first event by calling timer.setInitialDelay(delay),
where timer is the Timer and delay is specified
in milliseconds as usual.
Using Threads
Although Timers can replace threads in some cases, there
are times when direct use of threads is necessary. When a Timer
is used, the processing is done in an event handler. This means that
the processing must be something that can be done quickly. An event handler
should always finish its work quickly, so that the system can move on to
handle the next event. If an event handler runs for a long time, it will
block other events from being processed, and the program will become
unresponsive. So, in a GUI application, any computation or process that
will take a long time to complete should be run in a separate thread.
Then the event-handling thread can continue to run at the same time,
responding to user actions as they occur.
As a short and incomplete introduction to threads, we'll look at one
example. The example requires some explanation, but the main point
for our discussion of threads is that it is a realistic example of
a long computation that requires a separate thread.
The example is based on the Mandelbrot set, a mathematical
curiosity that has become familiar because it can be used to produce a
lot of pretty pictures. The Mandelbrot set has to do with the following
simple algorithm:
Start with a point (x,y) in the plane, where x and y are real numbers.
Let zx = x, and let zy = y.
Repeat the following:
Replace (zx,zy) with ( zx*zx - zy*zy + x, 2*zx*zy + y )
The question is, what will happen to the point (zx,zy) as the
loop is repeated over and over? The answer depends on the initial point (x,y).
For some initial points (x,y), the point (zx,zy) will, sooner or
later, move arbitrarily far away from the origin, (0,0). For other
starting points, the point (zx,zy) will stay close to (0,0)
no matter how many times you repeat the loop. The Mandelbrot set consists
of the (x,y) points for which (zx,zy) stays close to (0,0)
forever. This would probably not be very interesting, except that the Mandelbrot
set turns out to have an incredibly intricate and quite pretty structure.
To get a pretty picture from the Mandelbrot set, we change the question, just
a bit. Given a starting point (x,y), we ask, how many steps does it take,
up to some specified maximum number, before the point (zx,zy) moves some set
distance away from (0,0)? We then assign the point a color, depending on the
number of steps. If we do this for each (x,y), we get a kind of picture of
the set. For a point in the Mandelbrot set, the count always reaches the
maximum (since for such points, (zx,zy) never moves far away
from zero). For other points, in general, the closer the point is to the Mandelbrot
set, the more steps it will take.
With all that said, here is an applet that computes a picture of the Mandelbrot
set. It will begin its computation when you press the "Start" button. (Eventually,
the color of every pixel in the applet will be computed, but the applet actually
computes the colors progressively, filling the applet with smaller and smaller
blocks of color until it gets down to the single pixel level.) The applet represents
a region of the plane with -1.25 <= x <= 1.0
and -1.25 <= y <= 1.25. The Mandelbrot set
is colored purple. Points outside the set have other colors. Try it:
The algorithm for computing the colors in this applet is:
For square sizes 64, 32, 16, 8, 4, 2, and 1:
For each square in the applet:
Let (a,b) be the pixel coords of the center of the square.
Let (x,y) be the real numbers corresponding to (a,b).
Let (zx,zy) = (x,y).
Let count = 0.
Repeat until count is 80 or (zx,zy) is "big":
Let new_zx = zx*zx - zy*zy + x.
Let zy = 2*zx*zy + y.
Let zx = new_zx.
Let count = count + 1.
Let color = Color.getHSBColor( count/100.0F, 0.0F, 0.0F )
Fill the square with that color.
The point is that this is a long computation. When you click
the "Start" button of the applet, the applet creates a separate thread
to do this computation.
In Java, a thread is an object belonging to the class java.lang.Thread.
The purpose of a thread is to execute a single subroutine from beginning
to end. In the Mandelbrot
applet, that subroutine implements the above algorithm.
The subroutine for a thread is usually an instance method
public void run()
that is defined in an object that implements the interface named
Runnable. The Runnable interface defines run()
as its only method. The Runnable object is provided as
a parameter to the constructor of the thread object. (It is also possible
to define a thread by declaring a subclass of class Thread, and defining
a run() method in the subclass, but it is more common to use a Runnable
object to provide the run() method for a thread.) If runnableObject
is an object that implements the Runnable interface, then a thread
can be constructed with the command:
Thread runner = new Thread(runnableObject);
The job of this thread is to execute the run() method in runnableObject.
Just as with a Timer, it is not enough to construct a thread.
You must also start it running by calling its start method: runner.start().
When this method is called, the thread will begin executing the run() method
in the runnableObject, and it will do this in parallel with the rest of
the program. When the subroutine ends, the thread will die, and it cannot be restarted
or reused. There is no stop method for stopping a thread. (Actually, there is one, but
it is deprecated, meaning that you are not supposed to call it.) If you want to be
able to stop the thread, you need to provide some way of telling the thread to stop
itself. I often do this with an instance variable named running that
is visible both in the run() method and elsewhere in the program.
When the program wants the thread to stop, it just sets the value of running to false.
In the run() method, the thread checks the value of running regularly.
If it sees that the value of running has become false, then the
run() method should end. Here, for example, are the methods that the
Mandelbrot applet uses to start and to stop the thread:
void startRunning() {
// A simple method that starts the computational thread,
// unless it is already running. (This should be
// impossible since this method is only called when
// the user clicks the "Start" button, and that button
// is disabled when the thread is running.)
if (running)
return;
runner = new Thread(this);
// Creates a thread that will execute the run()
// method in this class, which implements Runnable.
running = true;
runner.start();
}
void stopRunning() {
// A simple method that is called to stop the computational
// thread. This is done by setting the value of the
// variable, running. The thread checks this value
// regularly and will terminate when running becomes false.
running = false;
}
There are a few more details of threads that you need to understand
before looking at the run() method from the applet. First,
on some platforms, once a thread starts running it grabs control of
the CPU, and no other thread can run until it yields
control. In Java,
a thread can yield control, and allow other threads to run, by calling
the static method Thread.yield(). I do this regularly in
the run() method of the applet. If I did not do this, then,
on some platforms, the computational thread would block the rest of the
program from running. Another way for a thread to yield control is
to go to sleep for a specified period of
time by calling Thread.sleep(time), where time is the
number of milliseconds for which the thread will be inactive. The thread
in a Timer, for example, sleeps between events, since it has
nothing else to do.
Another issue concerns the use of threads with Swing. There is a rule
in Swing: Don't touch any GUI components, or any data used by them,
except in the event-handling thread, that is, in event-handling methods
or in paintComponent(). The reason for this is that Swing
is not thread-safe. If more than one
thread plays with Swing's data structures, then the data can be
corrupted. (This is done for efficiency. Making Swing thread-safe
would slow it down significantly.) To solve this problem, Swing
has a way for another thread to get the event-handling thread to run a
subroutine for it. The subroutine must be a run() method
in a Runnable object. When a thread calls the static
method
void SwingUtilities.invokeAndWait(Runnable runnableObject)
the run() method of runnableObject will be executed in
the event-handling thread, where it can safely do anything it wants
to Swing components and their data. The invokeAndWait method,
as the name indicates, does not return until the run() method
has been executed. (The invokeAndWait method can produce an
exeception, and so must be called inside a try...catch statement.
I will cover try...catch statements in Chapter 9.
You can ignore it for now.)
The run() method for the
thread in the Mandelbrot applet uses SwingUtilities.invokeAndWait()
to color a square on the screen. Here, finally, is that run()
method (which will still take some work to understand):
public void run() {
// This is the run method that is executed by the
// computational thread. It draws the Mandelbrot
// set in a series of passes of increasing resolution.
// In each pass, it fills the applet with squares
// that are colored to represent the Mandelbrot set.
// The size of the squares is cut in half on each pass.
startButton.setEnabled(false); // Disable "Start" button
stopButton.setEnabled(true); // and enable "Stop" button
// while thread is running.
int width = getWidth(); // Current size of this canvas.
int height = getHeight();
OSI = createImage(getWidth(),getHeight());
// Create the off-screen image where the picture will
// be stored, and fill it with black to start.
OSG = OSI.getGraphics();
OSG.setColor(Color.black);
OSG.fillRect(0,0,width,height);
for (size = 64; size >= 1 && running; size = size/2) {
// Outer for loop performs one pass, filling
// the image with squares of the given size.
// The size here is given in terms of pixels.
// Note that all loops end immediately if running
// becomes false.
double dx,dy; // Size of square in real coordinates.
dx = (xmax - xmin)/width * size;
dy = (ymax - ymin)/height * size;
double x = xmin + dx/2; // x-coord of center of square.
for (i = size/2; i < width+size/2 && running; i += size) {
// First nested for loop draws one column of squares.
double y = ymax - dy/2; // y-coord of center of square
for (j = size/2; j < height+size/2 && running; j += size) {
// Innermost for loop draws one square, by
// counting iterations to determine what
// color it should be, and then invoking the
// "painter" object to actually draw the square.
colorIndex = countIterations(x,y);
try {
SwingUtilities.invokeAndWait(painter);
}
catch (Exception e) {
}
y -= dy;
}
x += dx;
Thread.yield(); // Give other threads a chance to run.
}
}
running = false; // The thread is about to end, either
// because the computation is finished
// or because running has been set to
// false elsewhere. In the former case,
// we have to set running = false here
// to indicate that the thread is no
// longer running.
startButton.setEnabled(true); // Reset states of buttons.
stopButton.setEnabled(false);
} // end run()
You can find the full source code in the file
Mandelbrot.java.
There is a lot more to be said about threads. I will not cover
it all in this book, but I will return to the topic in
Section 10.5.
