Swing Event-Handling Thread

A common first assumption when building an animation in a Swing application is that a timer is simply a convenient kind of thread. The reasoning 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, but they place your animation logic in different threads, and that difference determines whether your program is safe.

The reason this matters is that Swing does not protect its components and their state variables from being touched by several threads at once. Once you understand where your animation code actually runs, the potential for trouble becomes easy to see. The rest of this article follows the path of a timer event step by step, and then shows what goes wrong when the path is broken.

Think of the Swing Timer as a source of ticks. Its underlying thread does one job: it generates events at regular intervals. It does not draw anything, and it does not update your animation state. Each event is then 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.

The diagram shows the key point. The timer's thread stops after producing the event. The handler is then executed on the Swing event-handling thread, so any code that changes animation variables and any code that paints the frame end up on that same thread. 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. A separate thread that changes animation state while the GUI thread is reading that state is the situation to watch for. 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. Nothing in the code has to look wrong for this to happen. The overlap is simply a consequence of two threads running at once against shared data.

The overlap described above is a race condition. If paintComponent() reads the variables while updateForNextFrame() is partway through changing them, it may see a mixture of values. Some would belong to the new frame and some to the previous frame. The drawn picture would then be assembled from inconsistent data, even though each individual assignment was correct on its own.

The source gives two ways to protect against this. The first is to keep GUI state changes on the Swing event-handling thread. The second is to synchronize access to any shared variables that painting depends on. Either approach ensures that painting never reads variables in the middle of an update.

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. This is worth remembering because it is a common place where beginners worry unnecessarily. The reason is that repaint() does not paint anything itself. It only asks the system to schedule a paint event. The actual painting is carried out later, on the Swing event-handling thread.

So an animation thread can request a repaint freely. It should not, however, perform the drawing itself or change the variables that the drawing depends on without coordination. The safe call and the unsafe work are separate operations, and only the call is safe from any thread.

The two approaches differ in which thread does the work and which thread touches the GUI. The table below summarizes the structural differences described in the source.

The table makes the misconception visible. Both approaches produce a repeating animation, but only the timer keeps the animation logic on the thread that Swing expects. The extra code of a timer is not a shortcut around threading. It is a way of placing the work where it is safe.

The source also notes that Java includes another timer class, java.util.Timer, which is suited to non-GUI programs. The choice depends on context. A Swing Timer is designed to work with the Swing event-handling thread, which makes it a natural fit for GUI animation. A general-purpose timer suits work that has no graphical components to protect.