Skip to main content

skip to main content

developerWorks  >  Java technology  >

Gems from e-BIT: JViewport behaviour in JDK 1.3.0

developerWorks
Document options

Document options requiring JavaScript are not displayed


Rate this page

Help us improve this content


Level: Introductory

Heather Brailsford (dwinfo@us.ibm.com), Software engineer, IBM Hursley Lab

15 Jan 2002

You may have noticed that when using version 1.3.0 of the JDK, scroll and zoom operations in Swing applications sometimes appear jerky, or seem to flash temporary images before the final image is displayed. The same applications scroll smoothly using version 1.2.2. This tip explains the reasons for this behaviour.

The Swing JViewport class defines the part of an image that is visible at any one time. (Think of viewing the image through a porthole; the scrolling changes the viewing porthole.) The JScrollPane class handles connecting the scrollbars to the viewport. When the image is scrolled, the visible extents of the viewport are changed. The way the new image is displayed on the screen depends on the mode of scrolling being used. The default scroll mode has changed between 1.2.2 and 1.3.0, so the same application may behave differently on the two versions if the scroll mode is not explicitly set. The mode is set using the setScrollMode, as shown here:

setScrollMode(JViewport.SIMPLE_SCROLL_MODE)

There are three values that setScrollMode() can take:

  • SIMPLE_SCROLL_MODE: The complete scrollpane is redrawn for each scroll. This is the default in 1.2.2.

  • BACKINGSTORE_SCROLL_MODE: Images are buffered into a backingstore before being drawn. This provides performance benefits over SIMPLE_SCROLL_MODE but requires extra memory. This is still supported in 1.3, but has been deprecated.

  • BLIT_SCROLL_MODE: This algorithm was introduced in 1.2.2 to improve the performance of scrolling. With blitting, paint operations appear on the screen immediately instead of being buffered to an offscreen image until the complete image is ready to be displayed. Blitting improves performance in most cases because there is no need to maintain an offscreen buffer. An exception to this may be when scrolling an image that is hidden behind another window, or when part of the image is outside the screen area. In this case, a repaint operation is generated and performance will be adversely affected.

In 1.2.2 blitting was used only when explicitly set, but as it proved to be a significant performance improvement, it was made the default scroll mode in 1.3.0. One effect of using blit mode is that some of the intermediate paint operations may be visible on the screen while scrolling or zooming. This is usually more apparent with complex images. If this is unacceptable, you can set an alternate mode, but performance will almost certainly be affected.



About the author

Heather Brailsford is a software engineer at the IBM Hursley Lab.




Rate this page


Please take a moment to complete this form to help us better serve you.



YesNoDon't know
 


 


12345
Not
useful
Extremely
useful
 


Back to top