Using Swing Timers for Animation

A common first plan for animating a Swing application goes like this: if you can write an animation loop that runs on its own thread, then a Swing Timer must do the same job with less code. The two approaches look similar on the surface, and that similarity is exactly what makes the plan tempting. They are not the same thing. The two approaches place your animation logic in different threads, and that difference determines whether your program is safe.

Animation on a screen is an illusion built from a simple ingredient: a series of still pictures shown one after another. Java needs some way to decide when each new picture should appear, and the tool it offers for that job is a Timer, an object that produces a steady beat of events. Each beat gives your program an opportunity to compute the next picture and draw it. This article starts from a Timer-driven animation and works backward to the mechanism that makes it move, so that when something goes wrong you know where to look.

Think of the timer as a source of ticks. Its underlying thread generates an event at each interval, and then the event is handled by code that executes on the Swing event-handling thread. That same thread is responsible for repainting components and for responding to user actions such as mouse clicks and key presses. So the timer's thread and the handler's thread are different threads, and the handoff between them is what the diagram below traces.

The practical consequence is that the Swing event-handling thread is safe only when all the GUI work stays on it. As long as everything involving components and their variables happens there, the system behaves predictably. Trouble starts when another thread reaches into the same components or the same variables. Using a Timer keeps your handler on the right thread; writing your own loop on a separate thread does not.

Consider an animation class in which one method, updateForNextFrame(), changes several variables that describe the current frame, such as a position and a size. Another method, paintComponent(), reads those same variables in order to draw the frame. Suppose the animation logic calls updateForNextFrame() from a thread other than the Swing event-handling thread while paintComponent() is running on the Swing event-handling thread. The two methods can then overlap in time.

Here is the interleaving that causes trouble. The background thread begins updateForNextFrame() and assigns the new position. Before it gets to the new size, the Swing thread starts paintComponent() and reads the position and the size. The painter now sees a new position paired with an old size. The background thread then finishes its assignments, but the picture has already been drawn from a mixture of values. Each individual assignment was correct on its own; the problem is that the reader saw the variables in the middle of a change.

Not every GUI call carries the same risk. The repaint() method of a component can be called safely from any thread, without worrying about synchronization. Beginners often worry about this call unnecessarily. The reason is that repaint() does not paint anything itself. It only asks the system to schedule a paint event, and the actual painting is carried out later on the Swing event-handling thread.

So an animation thread can request a repaint freely, but it should not perform the drawing or change the variables that the drawing depends on without coordination. Requesting a repaint is a message to the painting machinery; changing the data that the paint reads is the part that still needs care.

A Timer does not do anything else with its events. It does not draw, compute, or update any data. Its only job is to announce that a moment has arrived. Whatever should happen at that moment has to be written somewhere else, in an object set up to listen for those announcements.

The source also notes that Java includes a different class, java.util.Timer, which suits non-GUI programs. The choice depends on whether the work touches Swing components at all. A Swing Timer is designed to work with the Swing event-handling thread, which is what makes it a natural fit for GUI animation.

A Timer on its own is not useful, because there is no point in a timer without something to respond to its events. The listener is therefore supplied when the Timer is constructed, and the delay between events is supplied at the same time. The listener must be an object that implements the ActionListener interface. In practice its class is declared to implement ActionListener and defines the one method the interface requires, actionPerformed. The method runs each time the Timer generates an event.

Creating a Timer and starting it are two separate steps. A timer does not begin generating events when the object is created. Until start() is called the Timer exists but is quiet, and the listener's actionPerformed method is never invoked. The stop() method turns the stream of events off, and the timer can be restarted later by calling start() again. A running Timer therefore moves through a small cycle: created but idle, running, stopped, and running again.

A computer animation is a sequence of still images presented one after another. Two conditions decide whether the viewer perceives continuous motion: the time between images must be short, and the change from one image to the next must not be too great. If both hold, the eye reads the sequence as one moving object rather than a slideshow. The Timer supplies the rhythm, and the code in actionPerformed supplies the content of each frame.

When an animation does not behave as expected, split the system into three checkpoints and work through them in order: first, whether the Timer was started; second, whether events are arriving at the listener; and third, whether actionPerformed computes and draws the frame you intended. The first checkpoint that fails tells you where the divergence happens.