Day 10

Simple Animation and Threads

by Laura Lemay

• Creating Animation in Java
  • Painting and Repainting
  • Starting and Stopping an Applet's Execution
  • The Missing Link: Threads
  • Putting It Together
• Threads: What They Are and Why You Need Them
  • Writing Applets with Threads
  • Another Look at the Digital Clock
• Reducing Animation Flicker
  • Flicker and How to Avoid It
  • How to Override update()
  • Solution One: Don't Clear the Screen
  • Solution Two: Redraw Only What You Have To
• Summary
• Q&A
  

The first thing I ever saw Java do was an animation: a large red Hi there! that ran across the screen from the right to left. Even that simple form of animation was enough to make me stop and think, "this is really cool."

That sort of simple animation takes only a few methods to implement in Java, but those few methods are the basis for any Java applet that you want to update the screen dynamically-for something as simple as flashy animation applets, or for more complex applets that may need to be updated based on data they get from the user, from databases connected to over the network, or from any other source.

Animation in Java is accomplished through various interrelated parts of the Java Abstract Windowing Toolkit (awt). Today you'll learn the fundamentals of animation in Java: how the various parts of the system all work together so that you can create moving figures and dynamically updatable applets. Specifically, you'll explore the following:

• How to create animation in Java-the paint() and repaint() methods, starting and stopping dynamic applets, and how to use and override these methods in your own applets
• Threads-what they are and how they can make your applets more well-behaved with other applets and with other parts of the awt
• Reducing animation flicker, which is a common problem with animation in Java

Throughout today, you'll also work with lots of examples of real applets that create animation or perform some kind of dynamic movement.

Creating Animation in Java

Animation in Java involves two basic steps: constructing a frame of animation, and then asking Java to paint that frame. You repeat these steps as necessary to create the illusion of movement. The basic, static graphical applets that you created yesterday taught you how to accomplish the first part; all that's left is how to tell Java to paint a frame.

Painting and Repainting

The paint() method, as you learned yesterday, is called whenever an applet needs to be painted-when the applet is initially drawn, when the window containing it is moved, or when another window is moved from over it. You can also, however, ask Java to repaint the applet at a time you choose. So, to change the appearance of what is on the screen, you construct the image or "frame" you want to paint, and then ask Java to paint this frame. If you do this repeatedly, and fast enough, you get animation inside your Java applet. That's all there is to it.

Where does all this take place? Not in the paint() method itself. All paint() does is put dots on the screen. paint(), in other words, is responsible only for the current frame of the animation. The real work of changing what paint() does, of modifying the frame for an animation, actually occurs somewhere else in the definition of your applet.

In that "somewhere else," you construct the frame (set variables for paint() to use, create Color or Font or other objects that paint() will need), and then call the repaint() method. repaint() is the trigger that causes Java to call paint() and causes your frame to get drawn.

Starting and Stopping an Applet's Execution

Remember start() and stop() from Day 8, "Java Applet Basics"? These are the methods that trigger your applet to start and stop running. You didn't use start() and stop() yesterday because the applets on that day did nothing except paint once. With animation and other Java applets that are actually processing and running over time, you'll need to make use of start() and stop() to trigger the start of your applet's execution, and to stop it from running when you leave the page that contains that applet. For many applets, you'll want to override start() and stop() for just this reason.

The start() method triggers the execution of the applet. You can either do all the applet's work inside that method, or you can call other object's methods in order to do so. Usually, start() is used to create and begin execution of a thread so the applet can run in its own time.

stop(), on the other hand, suspends an applet's execution so when you move off the page on which the applet is displaying, it doesn't keep running and using up system resources. Most of the time when you create a start() method, you should also create a corresponding stop().

The Missing Link: Threads

There's one more part to the animation mix that you'll have to know about, and that's threads. I'm going to discuss threads in a lot greater detail later on in this lesson (and in even more detail on Day 18, "Multithreading") but for now here's the basic idea: Anything you do in a Java program that runs continually and takes up a lot of processing time should run in its own thread. Animation is one of these things. To accomplish animation in Java, therefore, you use the start() method to start a thread, and then do all your animation processing inside the thread's run() method. This allows the animation to run on its own without interfering with any other parts of the program.

Putting It Together

Explaining how to do Java animation is more of a task than actually showing you how it works in code. An example will help make the relationship between all these methods clearer.

Listing 10.1 shows a sample applet that uses basic applet animation techniques to display the date and time and constantly updates it every second, creating a very simple animated digital clock (a frame from that clock is shown in Figure 10.1).

Figure 10.1 : The digital clock.

This applet uses the paint(), repaint(), start(), and stop() methods. It also uses threads. For this discussion, we'll focus on the animation parts of the applet and won't worry so much about how the threads work. We'll take another look at this applet later, after we've discussed threads in greater detail.

Listing 10.1. The DigitalClock applet.

 1: import java.awt.Graphics;
 2: import java.awt.Font;
 3: import java.util.Date;
 4:
 5: public class DigitalClock extends java.applet.Applet 
 6:   implements Runnable {
 7: 
 8:   Font theFont = new Font("TimesRoman",Font.BOLD,24);
 9:  Date theDate;
10:   Thread runner;
11: 
12:   public void start() {
13:     if (runner == null) {
14:       runner = new Thread(this);
15:       runner.start();
16:     }
17:   }
18:
19:   public void stop() {
20:     if (runner != null) {
21:       runner.stop();
21:       runner = null;
22:     }
23:   }
24:  
25:   public void run() {
26:     while (true) {
27:       theDate = new Date();
28:       repaint();
29:      try { Thread.sleep(1000); }
30:       catch (InterruptedException e) { }
31:     }
32:   }
33: 
34:   public void paint(Graphics g) {
35:     g.setFont(theFont);
36:     g.drawString(theDate.toString(),10,50);
37:   }
38:}

Lines 7 and 8 define two basic instance variables: theFont and theDate, which hold objects representing the current font and the current date, respectively. You'll learn more about these later.

The start() and stop() methods here start and stop a thread; the bulk of the applet's work goes on in the run() methods (lines 25 to 32).

Inside run() is where the animation actually takes place. Note the while loop inside this method (line 26); given that the test (true) always returns true, the loop never exits. A single animation frame is constructed inside that while loop, with the following steps:

• The Date class represents a date and time (Date is part of the java.util package-note that it was specifically imported in line 3). Line 27 creates a new instance of the Date class, which holds the current date and time, and assigns it to the theDate instance variable.
• The repaint() method is called (line 28) to repaint the applet.
• Lines 14 and 15, as complicated as they look, do nothing except pause for 1000 milliseconds (1 second) before the loop repeats. The sleep() method there, part of the Thread class, is what causes the applet to pause. Without a specific sleep() method, the applet would run as fast as it possibly could, which, for most computer systems, would be too fast for the eye to see. The sleep() method controls exactly how fast the animation takes place. The try and catch stuff around it enables Java to manage errors if they occur. try and catch handle exceptions and are described on Day 17, "Exceptions."

On to the paint() method in lines 34 through 37. Here, inside paint(), all that happens is that the current font (in the variable theFont) is set, and the date itself is printed to the screen (note that you have to call the toString() method to convert the date to a string). Because paint() is called repeatedly with whatever value happens to be in theDate, the string is updated every second to reflect the new date.

There are a few things to note about this example. First, you might think it would be easier to create the new Date object inside the paint() method. That way you could use a local variable and not need an instance variable to pass the Date object around. Although doing things that way creates cleaner code, it also results in a less efficient program. The paint() method is called every time a frame needs to be changed. In this case, it's not that important, but in an animation that needs to change frames very quickly, the paint() method has to pause to create that new object every time. By leaving paint() to do what it does best-painting the screen-and calculating new objects beforehand, you can make painting as efficient as possible. This is precisely the same reason why the Font object is also in an instance variable.

Threads: What They Are and Why You Need Them

So what are these threads all about? Why are they important to animation?

Threads are a very important part of Java and of programming Java. The larger your Java programs get and the more things they do, the more likely it is that you'll want to use threads. Depending on your experience with operating systems and with environments within those systems, you may or may not have run into the concept of threads, so let's start from the beginning.

First, the analogy. A group of students is on a bus, on a field trip somewhere. To pass the time, the teachers are leading a sing-along. As the trip progresses, the students sing one song, then when that song is done, they sing another song. While different parts of the bus could sing different songs, it wouldn't sound very good, so the singing of one song monopolizes the time until its done, at which time another song can start.

Now let's say you have two busses; both are on the same route to the field trip, both are going at the same speed, and both are full of students singing songs. But the songs being sung by the students in the second bus don't interfere with the songs being sung in the first bus; in this way you can get twice as many songs sung in the same amount of time by singing them in parallel.

Threads are like that. In a regular single-threaded program, the program starts executing, runs its initialization code, calls methods or procedures, and continues running and processing until it's complete or until the program is exited. That program runs in a single thread-it's the one bus with all the students.

Multithreading, as in Java, means that several different parts of the same program can run at the same time, in parallel, without interfering with each other. Multiple threads, each running by itself, are like multiple busses with different things going on in each bus.

Here's a simple example. Suppose you have a long computation near the start of a program's execution. This long computation may not be needed until later in the program's execution-it's actually tangential to the main point of the program, but it needs to get done eventually. In a single-threaded program, you have to wait for that computation to finish before the rest of the program can continue running. In a multithreaded system, you can put that computation into its own thread, and the rest of the program can continue to run independently.

Animation is an example of the kind of task that needs its own thread. Take, for example, that digital clock applet, which has an endless while() loop. If you didn't use threads, while() would run in the default Java system thread, which is also responsible for handling painting the screen, dealing with user input like mouse clicks, and keeping everything internally up- to-date. Unfortunately, however, if you run that while() loop in the main system thread, it will monopolize all Java's resources and prevent anything else-including painting-from happening. You'd never actually see anything on the screen because Java would be sitting and waiting for the while() loop to finish before it did anything else. And that's not what you want.

Using threads in Java, you can create parts of an applet (or application) that run in their own threads, and those parts will happily run all by themselves without interfering with anything else. Depending on how many threads you have, you may eventually tax the system so that all of them will run slower, but all of them will still run independently.

Even if you don't use lots of them, using threads in your applets is a good Java programming practice. The general rule of thumb for well-behaved applets: Whenever you have any bit of processing that is likely to continue for a long time (such as an animation loop, or a bit of code that takes a long time to execute), put it in a thread.

Writing Applets with Threads

Creating applets that use threads is very easy. In fact, many of the basic things you need to do to use threads are just boilerplate code that you can copy and paste from one applet to another. Because it's so easy, there's almost no reason not to use threads in your applets, given the benefits.

There are four modifications you need to make to create an applet that uses threads:

• Change the signature of your applet class to include the words implements Runnable.
• Include an instance variable to hold the applet's thread object.
• Create a start() method that does nothing but create a thread and start it running.
• Create a stop() method that stops the thread.
• Create a run() method that contains the actual code that controls the applet.

The first change is to the first line of your class definition. You've already got something like this:

public class MyAppletClass extends java.applet.Applet {
...
}

You need to change it to the following:

public class MyAppletClass extends java.applet.Applet  implements Runnable {
...
}

What does this do? It includes support for the Runnable interface in your applet. If you think way back to Day 2, "Object-Oriented Programming and Java," you'll remember that interfaces are a way to collect method names common to different classes, which can then be mixed in and implemented inside different classes that need to implement that behavior. Here, the Runnable interface defines the behavior your applet needs to run a thread; in particular, it gives you a default definition for the run() method. By implementing Runnable, you tell others that they can call the Run() method on your instances.

The second step is to add an instance variable to hold this applet's thread. Call it anything you like; it's a variable of the type Thread (Thread is a class in java.lang, so you don't have to import it):

Thread runner;

Third, add a start() method or modify the existing one so that it does nothing but create a new thread and start it running. Here's a typical example of a start() method:

public void start() {
   if (runner == null) {
       runner = new Thread(this);
       runner.start();
   }
}

If you modify start() to do nothing but spawn a thread, where does the code that drives your applet go? It goes into a new method, run(), which looks like this:

public void run() {
    // what your applet actually does
}

Your run() method actually overrides the default version of run(), which you get when you include the Runnable interface with your applet. run() is one of those standard methods, like start() and paint(), that you override in your own classes to get standard behavior.

run() can contain anything you want to run in the separate thread: initialization code, the actual loop for your applet, or anything else that needs to run in its own thread. You also can create new objects and call methods from inside run(), and they'll also run inside that thread. The run() method is the real heart of your applet.

Finally, now that you've got threads running and a start() method to start them, you should add a stop() method to suspend execution of that thread (and therefore whatever the applet is doing at the time) when the reader leaves the page. stop(), like start(), is usually something along these lines:

public void stop() {
  if (runner != null) {
      runner.stop();
      runner = null;
  }
}

The stop() method here does two things: It stops the thread from executing and also sets the thread's variable runner to null. Setting the variable to null makes the Thread object it previously contained available for garbage collection so that the applet can be removed from memory after a certain amount of time. If the reader comes back to this page and this applet, the start() method creates a new thread and starts up the applet once again.

And that's it! Four basic modifications, and now you have a well-behaved applet that runs in its own thread.

Another Look at the Digital Clock

Let's take another look at that DigitalClock applet, this time from the standpoint of threads. Listing 10.2 shows that applet's code once again.

Listing 10.2. The DigitalClock applet, revisited.

 1: import java.awt.Graphics;
 2: import java.awt.Font;
 3: import java.util.Date;
 4:
 5: public class DigitalClock extends java.applet.Applet 
 6:   implements Runnable {
 7: 
 8:   Font theFont = new Font("TimesRoman",Font.BOLD,24);
 9:  Date theDate;
10:   Thread runner;
11: 
12:   public void start() {
13:     if (runner == null) {
14:       runner = new Thread(this);
15:       runner.start();
16:     }
17:   }
18:
19:   public void stop() {
20:     if (runner != null) {
21:       runner.stop();
21:       runner = null;
22:     }
23:   }
24:  
25:   public void run() {
26:     while (true) {
27:       theDate = new Date();
28:       repaint();
29:      try { Thread.sleep(1000); }
30:       catch (InterruptedException e) { }
31:     }
32:   }
33: 
34:   public void paint(Graphics g) {
35:     g.setFont(theFont);
36:     g.drawString(theDate.toString(),10,50);
37:   }
38:}

Line 10 defines a third instance variable for this class called runner of type Thread, which will hold the thread object for this applet.

Lines 12 through 23 define the boilerplate start() and stop() methods that do nothing except create and destroy threads. These method definitions can essentially be exactly the same from class to class because all they do is set up the infrastructure for the thread itself.

And, finally, the bulk of your applet's work goes on inside the run() method in lines 25 through 32, as we already discussed the last time we looked at this applet. Inside this method is the endless while loop, the calls to repaint(), and the sleep() method, which pauses things so they only run once a second.

Reducing Animation Flicker

If you've been following along with this lesson and trying the examples as you go, rather than reading this book on an airplane or in the bathtub, you may have noticed that when the digital clock program runs, every once in a while there's an annoying flicker in the animation. (Not that there's anything wrong with reading this book in the bathtub, but you won't see the flicker if you do that, so just trust me-there's a flicker.) This isn't a mistake or an error in the program; in fact, that flicker is a side effect of creating animation in Java. Because it is really annoying, you'll learn how to reduce flicker in this part of today's lesson so that your animations run cleaner and look better on the screen.

Flicker and How to Avoid It

Flicker is caused by the way Java paints and repaints each frame of an applet. At the beginning of today's lesson, you learned that when you call the repaint() method, repaint() calls paint(). That's not precisely true. A call to paint() does indeed occur in response to a repaint(), but what actually happens are the following steps:

1. The call to repaint() results in a call to the method update().
2. The update() method clears the screen of any existing contents (in essence, fills it with the current background color), and then calls paint().
3. The paint() method then draws the contents of the current frame.

It's step 2, the call to update(), that causes animation flicker. Because the screen is cleared between frames, the parts of the screen that don't change alternate rapidly between being painted and being cleared. Hence, flickering.

There are two major ways to avoid flicker in your Java applets:

• Override update() either not to clear the screen at all, or to clear only the parts of the screen you've changed.
• Override both update() and paint(), and use double-buffering.

If the second way sounds complicated, that's because it is. Double-buffering involves drawing to an offscreen graphics surface and then copying that entire surface to the screen. Because it's more complicated, you'll explore that one tomorrow. Today let's cover the easier solution: overriding update().

How to Override update()

The cause of flickering lies in the update() method. To reduce flickering, therefore, override update(). Here's what the default version of update() does (comes from the Component class, is part of the awt, and is one of the superclasses of the applet class. You'll learn more about it on Day 13, "Creating User Interfaces with the awt"):

public void update(Graphics g) {
    g.setColor(getBackground());
    g.fillRect(0, 0, width, height);
    g.setColor(getForeground());
    paint(g);
}

Basically, update() clears the screen (or, to be exact, fills the applet's bounding rectangle with the background color), sets things back to normal, and then calls paint(). When you override update(), you have to keep these two things in mind and make sure that your version of update() does something similar. In the next two sections, you'll work through some examples of overriding update() in different cases to reduce flicker.

Solution One: Don't Clear the Screen

The first solution to reducing flicker is not to clear the screen at all. This works only for some applets, of course. Here's an example of an applet of this type. The ColorSwirl applet prints a single string to the screen ("All the Swirly Colors"), but that string is presented in different colors that fade into each other dynamically. This applet flickers terribly when it's run. Listing 10.3 shows the initial source for this applet, and Figure 10.2 shows the result.

Figure 10.2 : The ColorSwirl applet.

Listing 10.3. The ColorSwirl applet.

 1:  import java.awt.Graphics;
 2:  import java.awt.Color;
 3:  import java.awt.Font;
 4: 
 5: public class ColorSwirl extends java.applet.Applet
 6:     implements Runnable {
 7:
 8:    Font f = new Font("TimesRoman",Font.BOLD,48);
 9:    Color colors[] = new Color[50];
10:    Thread runThread;
11:
12:    public void start() {
13:        if (runThread == null) {
14:            runThread = new Thread(this);
15:            runThread.start();
16:        }
17:    }
18:
19:    public void stop() {
20:        if (runThread != null) {
21:            runThread.stop();
22:            runThread = null;
23:        }
24:    }
25:
26:    public void run() {
27:
28:        // initialize the color array
29:        float c = 0;
30:        for (int i = 0; i < colors.length; i++) {
31:            colors[i] =
32:            Color.getHSBColor(c, (float)1.0,(float)1.0);
33:            c += .02;
34:        }
35:
36:        // cycle through the colors
37:        int i = 0;
38:        while (true) {
39:            setForeground(colors[i]);
40:            repaint();
41:            i++;
42:            try { Thread.sleep(50); }
43:            catch (InterruptedException e) { }
44:            if (i == colors.length ) i = 0;
45:        }
46:    }
47:
48:    public void paint(Graphics g) {
49:        g.setFont(f);
50:        g.drawString("All the Swirly Colors", 15, 50);
51:    }
52: }]

• Line 9 defines an instance variable Colors, which is an array of 50 elements. When the applet starts, the first thing you do in the run() method (in lines 28 through 34) is to fill up that array with color objects. By creating all the colors beforehand, you can then jusxt draw text in that color, one at a time; it's easier to precompute all the colors at once (and, in fact, this for loop might make more sense in an init() method because it only needs to happen once). Note that I arbitrarily picked the number 50 for the number of colors we'll be using; we could just as easily cycle through 20 or 250 colors.
• To create the different color objects, we used a method in the Color class called getHSBColor(), rather than just using new with various RGB values. The getHSBColor() class method creates a color object based on values for hue, saturation, and brightness, rather than the standard red, green, and blue. HSB is simply a different way of looking at colors, and by incrementing the hue value and keeping saturation and brightness constant, you can create a range of colors without having to know the RGB for each one. If you don't understand this, don't worry about it; it's just a quick and easy way to create the color array.
• To create the animation, the applet cycles through the array of colors, setting the foreground color to each color object in turn and calling repaint(). When it gets to the end of the array, it starts over again (line 44), so the process repeats over and over ad infinitum.

Now that you understand what the applet does, let's fix the flicker. Flicker here results because each time the applet is painted, there's a moment where the screen is cleared. Instead of the text cycling neatly from red to a nice pink to purple, it's going from red to gray, to pink to gray, to purple to gray, and so on-not very nice looking at all.

Because the screen clearing is all that's causing the problem, the solution is easy: Override update() and remove the part where the screen gets cleared. It doesn't really need to get cleared anyhow, because nothing is changing except the color of the text. With the screen clearing behavior removed from update(), all update needs to do is call paint(). Here's what the update() method looks like in this applet (you'll want to add it after the paint() method after line 51):

public void update(Graphics g) {
   paint(g);
}

With that-with one small three-line addition-no more flicker. Wasn't that easy?

Solution Two: Redraw Only What You Have To

For some applets, it won't be quite as easy as just not clearing the screen. With some kinds of animation, clearing the screen is necessary for the animation to work properly. Here's another example. In this applet, called Checkers, a red oval (a checker piece) moves from a black square to a white square, as if on a checkerboard. Listing 10.4 shows the code for this applet, and Figure 10.3 shows the applet itself.

Figure 10.3 : The Checkers applet.

Listing 10.4. The Checkers applet.

 1:   import java.awt.Graphics;
 2:     import java.awt.Color;
 3: 
 4:   public class Checkers extends java.applet.Applet
 5:       implements Runnable {
 6: 
 7:       Thread runner;
 8:       int xpos;
 9: 
10:       public void start() {
11:          if (runner == null) {
12:              runner = new Thread(this);
13:              runner.start();
14:          }
15:      }
16: 
17:      public void stop() {
18:          if (runner != null) {
19:              runner.stop();
20:              runner = null;
21:          }
22:      }
23:  
24:  public void run() {
25:      setBackground(Color.blue);
26:      while (true) {
27:          for (xpos = 5; xpos <= 105; xpos+=4) {
28:              repaint();
29:              try { Thread.sleep(100); }
30:              catch (InterruptedException e) { }
31:          }
32:          xpos = 5;
33:      }
34:  }
35: 
36:      public void paint(Graphics g) {
37:          // Draw background
38:          g.setColor(Color.black);
39:         g.fillRect(0, 0, 100, 100);
40:          g.setColor(Color.white);
41:          g.fillRect(101, 0, 100, 100);
42: 
43:          // Draw checker
44:          g.setColor(Color.red);
45:          g.fillOval(xpos, 5, 90, 90);
46:     }
47:  }

In the actual paint() method, the background squares are painted (one black and one white), and then the checker is drawn at its current position.

This applet, like the ColorSwirl applet, also has a terrible flicker. (In line 25, I changed the background color to blue to emphasize it, so if you run this applet, you'll definitely see the flicker.)

However, the solution to solving the flicker problem for this applet is more difficult than for the last one, because you actually do want to clear the screen before the next frame is drawn. Otherwise, the red checker won't have the appearance of leaving one position and moving to another; it'll just leave a red smear from one side of the checkerboard to the other.

How do you get around this? You still clear the screen, in order to get the animation effect, but, rather than clearing the entire screen each time, you clear only the part that has actually changed from one frame to the next. By limiting the redraw to only a small area, you can eliminate some of the flicker you get from redrawing the entire screen.

To limit what gets redrawn, you need a couple things. First, you need a way to restrict the drawing area so that each time paint() is called, only the part that needs to get redrawn actually gets redrawn. Fortunately, this is easy by using a mechanism called clipping. Clipping, part of the graphics class, enables you to restrict the drawing area to a small portion of the full screen; although the entire screen may get instructions to redraw, only the portions inside the clipping area are actually drawn.

The second thing you need is a way to keep track of the actual area to redraw. Both the left and right edges of the drawing area change for each frame of the animation (one side to draw the new oval, the other to erase the bit of the oval left over from the previous frame), so to keep track of those two x values, you need instance variables for both the left side and the right.

With those two concepts in mind, let's start modifying the Checkers applet to redraw only what needs to be redrawn. First, you'll add instance variables for the left and right edges of the drawing area. Let's call those instance variables ux1 and ux2 (u for update), where ux1 is the left side of the area to draw and ux2 the right:

int ux1,ux2;

Now let's modify the run() method so that it keeps track of the actual area to be drawn, which you would think is easy-just update each side for each iteration of the animation. Here, however, things can get complicated because of the way Java uses paint() and repaint().

The problem with updating the edges of the drawing area with each frame of the animation is that for every call to repaint() there may not be an individual corresponding paint(). If system resources get tight (because of other programs running on the system or for any other reason), paint() may not get executed immediately and several calls to paint() may queue up waiting for their turn to change the pixels on the screen. In this case, rather than trying to make all those calls to paint() in order (and be potentially behind all the time), Java catches up by executing only the most recent call to paint() and skips all the others.

This poses a difficult problem in the Checkers applet. If you update the edges of the drawing area with each call to repaint(), and a couple calls to paint() are skipped, you end up with bits of the drawing surface not being updated at all or bits of the oval (colloquially called "turds") left behind. Because of how repaint() and paint() work in Java, you cannot guarantee that every single clipping region will eventually get painted-some may be skipped. The way to solve this is not to reset the clipping region to something new every single pass, but instead to reset the region only if that region was indeed updated. This way, if a couple of calls to paint() get skipped, the area to be updated will get larger for each frame, and when paint() finally gets caught up, everything will get repainted correctly.

Yes, this is horrifyingly complex. If I could have written this applet more simply, I would have (and, in fact, I did make it as simple as I could after much rewriting), but without this mechanism the applet will not get repainted correctly (my first try at this applet left turds all over the place). Let's step through it slowly in the code so you can get a better grasp of what's going on at each step.

Let's start with run(), where each frame of the animation takes place. Here's where you calculate each side of the clipping area based on the old position of the oval and the new position of the oval. The value of ux1 (the left side of the drawing area) is the previous oval's x position (xpos), and the value of ux2 is the x position of the current oval plus the width of that oval (90 pixels in this example).

Here's what the old run() method looked like:

public void run() {
    setBackground(Color.blue);
    while (true) {
        for (xpos = 5; xpos <= 105; xpos += 4) {
            repaint();
            try { Thread.sleep(100); }
            catch (InterruptedException e) { }
        }
        xpos = 5;
    }
}

For each step in which the oval moves toward the right, you first update ux2 (the right edge of the drawing area):

ux2 = xpos + 90;

Then, after the repaint() has occurred, you can update ux1 to reflect the old x position of the oval. However, you want to update this value only if the paint actually happened, so you don't end up skipping bits of the screen. How can you tell if the paint actually happened? You can reset ux1 in paint() to a given value (say 0), and then test inside run() to see whether you can update that value or whether you have to wait for the paint() to occur:

if (ux1 == 0) ux1 = xpos;

Finally, there's one other change to make. When the oval reaches the right side of the screen and resets back to its original position, there's one frame where you want to redraw the whole screen rather than create a clipping region (otherwise, the image of the oval would remain on the right side of the screen). So, in this one case, you want to set ux2 to be the full width of the applet. Here we'll modify the line we just put in to set the value of ux2, using an if statement to test to see if the oval is at the left side of the screen:

if (xpos == 5) ux2 = size().width;
else ux2 = xpos + 90;

The size() method is used to get the dimensions of the applet; size().width gives the full width of the applet so that the entire drawing surface will be updated.

Here's the new version of run() with those changes in place:

public void run() {
    setBackground(Color.blue);
    while (true) {
      for (xpos = 5; xpos <= 105; xpos+=4) {
         if (xpos == 5) ux2 = size().width;
         else ux2 = xpos + 90;
         repaint();
         try { Thread.sleep(100); }
         catch (InterruptedException e) { }
         if (ux1 == 0) ux1 = xpos;
      }
      xpos = 5;
    }
  }

Those are the only modifications run() needs. Let's override update() to limit the region that is being painted to the left and right edges of the drawing area that you set inside run(). To clip the drawing area to a specific rectangle, use the clipRect() method. clipRect(), like drawRect(), fillRect(), and clearRect(), is defined for Graphics objects and takes four arguments: x and y starting positions, and the width and height of the region.

Here's where ux1 and ux2 come into play. ux1 is the x point of the top corner of the region; then use ux2 to get the width of the region by subtracting ux1 from that value. The y values are the standard y values for the oval, which don't vary at all (the oval starts at y position 5 and ends at 95). Finally, to finish update(), you call paint():

public void update(Graphics g) {
   g.clipRect(ux1, 5, ux2 - ux1, 95);
   paint(g);
 }

Note that with the clipping region in place, you don't have to do anything to the actual paint() method. paint() goes ahead and draws to the entire screen each time, but only the areas inside the clipping region actually get changed onscreen.

You will need to make one change to paint(), however. You need to update the trailing edge of each drawing area inside paint() in case several calls to paint() were skipped. Because you are testing for a value of 0 inside run(), inside paint() you can merely reset ux1 and ux2 to 0 after drawing everything:

ux1 = ux2 = 0;

Those are the only changes you have to make to this applet in order to draw only the parts of the applet that changed (and to manage the case where some frames don't get updated immediately). Although this doesn't totally eliminate flickering in the animation, it does reduce it a great deal. Try it and see. Listing 10.5 shows the final code for the Checkers applet (called Checkers2.java).

Listing 10.5. The final Checkers applet.

 1: import java.awt.Graphics;
 2: import java.awt.Color;
 3: 
 4: public class Checkers2 extends java.applet.Applet implements Runnable {
 5: 
 6:     Thread runner;
 7:     int xpos;
 8:     int ux1,ux2;
 9: 
10:     public void start() {
11:         if (runner == null) {
12:             runner = new Thread(this);
13:             runner.start();
14:         }
15:     }
16:
17:     public void stop() {
18:         if (runner != null) {
19:             runner.stop();
20:             runner = null;
21:         }
22:     }
23:
24:     public void run() {
25:        setBackground(Color.blue);
26:        while (true) {
27:          for (xpos = 5; xpos <= 105; xpos+=4) {
28:             if (xpos == 5) ux2 = size().width;
29:             else ux2 = xpos + 90;
30:             repaint();
31:             try { Thread.sleep(100); }
32:             catch (InterruptedException e) { }
33:             if (ux1 == 0) ux1 = xpos;
34:          }
35:          xpos = 5;
36:        }
37:    }
38: 
39:     public void update(Graphics g) {
40:         g.clipRect(ux1, 5, ux2 - ux1, 95);
41:         paint(g);
42:     }
43: 
44:     public void paint(Graphics g) {
45:         // Draw background
46:         g.setColor(Color.black);
47:         g.fillRect(0, 0, 100, 100);
48:         g.setColor(Color.white);
49:         g.fillRect(101, 0, 100, 100);
50: 
51:         // Draw checker
52:         g.setColor(Color.red);
53:         g.fillOval(xpos, 5, 90, 90);
54:
55:         // reset the drawing area
56:         ux1 = ux2 = 0;
57:     }
58:}

Summary

Congratulations on getting through Day 10! This day was a bit rough; you've learned a lot, and it all might seem overwhelming. You learned about a plethora of methods to use and override-start(), stop(), paint(), repaint(), run(), and update()-and you got a basic foundation in creating and using threads. Other than handling bitmap images, which you'll learn about tomorrow, you now have the basic background to create just about any animation you want in Java.

Q&A