And finally, Swing provides the Swing's double buffer mechanism uses a single offscreen buffer per containment hierarchy (usually per top-level window) where double-buffering has been enabled.
And although this property can be set on a per-component basis, the result of setting it on a particular container will have the effect of causing all lightweight components underneath that container to be rendered into the offscreen buffer, regardless of their individual "double Buffered" property values.
After JDK 1.1, when the Swing toolkit was released, it introduced its own spin on painting components.
Why do we make a distinction between "system-triggered" and. Because AWT treats each of these cases slightly differently for heavyweight components (the lightweight case will be discussed later), which is unfortunately a source of great confusion.
For heavyweight components, these two types of painting happen in the two distinct ways, depending on whether a painting operation is system-triggered or app-triggered.
This scheme took care of details such as damage detection, clip calculation, and z-ordering.
With the introduction of components in JDK 1.1 (a "lightweight" component is one that reuses the native window of its closest heavyweight ancestor), the AWT needed to implement the paint processing for lightweight components in the shared Java code.
This is handled by to do incremental painting must ensure that lightweight descendents are recursively repainted if necessary.