AWT Painting Guidelines
The AWT provides a simple callback API for painting components. When you use it, the following guidelines apply:
- For most programs, all client paint code should be placed within the scope of the component's
paint()
method. - Programs may trigger a future call to
paint()
by invokingrepaint()
, but shouldn't callpaint()
directly. - On components with complex output,
repaint()
should be invoked with arguments which define only the rectangle that needs updating, rather than the no-arg version, which causes the entire component to be repainted. - Since a call to
repaint()
results first in a call toupdate()
, which is forwarded topaint()
by default, heavyweight components may overrideupdate()
to do incremental drawing if desired (lightweights do not support incremental drawing) - Extensions of
java.awt.Container
which overridepaint()
should always invokesuper.paint()
to ensure children are painted. - Components which render complex output should make smart use of the clip rectangle to narrow the drawing operations to those which intersects with the clip area.
Swing Painting Guidelines
Swing programs should understand these guidelines when writing paint code:
- For Swing components,
paint()
is always invoked as a result of both system-triggered and app-triggered paint requests;update()
is never invoked on Swing components. - Programs may trigger a future call to
paint()
by invokingrepaint()
, but shouldn't callpaint()
directly. - On components with complex output,
repaint()
should be invoked with arguments which define only the rectangle that needs updating, rather than the no-arg version, which causes the entire component to be repainted. - Swing's implementation of
paint()
factors the call into 3 separate callbacks:paintComponent()
paintBorder()
paintChildren()
paintComponent()
method (not withinpaint()
). - Swing introduces two properties to maximize painting efficiency:
opaque
: will the component paint all its bits or not?optimizedDrawingEnabled
: may any of this component's children overlap?
- If a Swing component's
opaque
property is set totrue
, then it is agreeing to paint all of the bits contained within its bounds (this includes clearing it's own background withinpaintComponent()
), otherwise screen garbage may result. -
Setting either the
opaque
oroptimizedDrawingEnabled
properties tofalse
on a component will cause more processing on each paint operation, therefore we recommend judicious use of both transparency and overlapping components. -
Extensions of Swing components which have UI delegates (including
JPanel
), should typically invokesuper.paintComponent()
within their ownpaintComponent()
implementation. Since the UI delegate will take responsibility for clearing the background on opaque components, this will take care of #5. -
Swing supports built-in double-buffering via the
JComponent
doubleBuffered
property, and it defaults totrue
for all Swing components, however setting it totrue
on a Swing container has the general effect of turning it on for all lightweight descendents of that container, regardless of their individual property settings. -
It is strongly recommended that double-buffering be enabled for all Swing components.
-
Components which render complex output should make smart use of the clip rectangle to narrow the drawing operations to those which intersect with the clip area.