Repainting is a fundamental task for a graphical
application, but one that is rarely explained in the detail you’d expect
for something so central. This section is intended to give you a better
feel for how painting and repainting via the repaint manager and
JComponent work. You typically do not
need to get involved with the
RepaintManager class, and only the extremely
brave override it. However, there are some instances in which a firm
understanding of the repaint manager can help avoid confusion, and,
starting with SDK 1.4, Swing provides a way for savvy code to take
advantage of accelerated graphics hardware when it is available.
Recall that Swing uses lightweight components, which are drawn
inside heavyweight top-level containers. Since the operating system
has no knowledge of lightweight components (that’s what makes them
lightweight), it can’t help coordinate their repainting. To continue
the analogy first presented in the earlier lightweight and heavyweight
discussion, Swing is responsible for painting and repainting
everything inside its own easels. Swing delegates this duty to a
RepaintManager class, which
organizes and schedules repainting when told to do so.
RepaintManager class is responsible for keeping track of the
components (and the components’ parts) that have become
dirty, which means that they need to be repainted. Note that the “dirty region” does not necessarily include the entire region ...