The "viewport" or "porthole" through which you see the underlying information. When you scroll, what moves is the viewport. It is like peering through a camera's viewfinder. Moving the viewfinder upwards brings new things into view at the top of the picture and loses things that were at the bottom.
By default, JViewport is opaque. To change this, use the setOpaque method.
NOTE:We have implemented a faster scrolling algorithm that does not require a buffer to draw in. The algorithm works as follows:
- The view and parent view are checked to see if they are
JComponents, if they aren't, stop and repaint the whole viewport.
- If the viewport is obscured by an ancestor, stop and repaint the whole viewport.
- Compute the region that will become visible, if it is as big as the viewport, stop and repaint the whole view region.
- Obtain the ancestor
Window's graphics and do a copyArea on the scrolled region.
- Message the view to repaint the newly visible region.
- The next time paint is invoked on the viewport, if the clip region is smaller than the viewport size a timer is kicked off to repaint the whole region.
In general this approach is much faster. Compared to the backing store approach this avoids the overhead of maintaining an offscreen buffer and having to do two
copyAreas. Compared to the non backing store case this approach will greatly reduce the painted region.
This approach can cause slower times than the backing store approach when the viewport is obscured by another window, or partially offscreen. When another window obscures the viewport the copyArea will copy garbage and a paint event will be generated by the system to inform us we need to paint the newly exposed region. The only way to handle this is to repaint the whole viewport, which can cause slower performance than the backing store case. In most applications very rarely will the user be scrolling while the viewport is obscured by another window or offscreen, so this optimization is usually worth the performance hit when obscured.
Warning: Swing is not thread safe. For more information see Swing's Threading Policy .
Warning: Serialized objects of this class will not be compatible with future Swing releases. The current serialization support is appropriate for short term storage or RMI between applications running the same version of Swing. As of 1.4, support for long term storage of all JavaBeans has been added to the java.beans package. Please see XMLEncoder.