JDK-6415339 : Swing doesn't refresh properly
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2006-04-19
  • Updated: 2017-05-16
  • Resolved: 2006-05-31
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
6 b86Fixed
Related Reports
Relates :  
Relates :  
Relates :  
A simple application that I wrote seems to have some refresh issues with Swing when running with Mustang (this problem doesn't happen with Tiger). It seems as if, when Swing needs to refresh, it uses an out-of-date buffer instead of calling the paintComponent() method.

To recreate the problem you need the two files I attached to the CR (a .jar file with the application and a .gz file which is the trace file the application will read).

Run it like this:

java -jar GCVis.jar spec.jack.trace.4.gz 1 100

When the window appears, press Start and you'll see the text "Marking Start" at the top-left. Do that a few times until the text "Compaction Start" appears at the to-left. Now, try to cause a refresh by moving another window in front of the application window or iconify / de-iconify the application window. In most cases, but not all, the refresh in the JPanel that has the graphics will be incorrect and the window will either be totally gray or pick up out-of-date contents (the labels at the top and buttons at the bottom seem to be refreshed correctly).

If I do the above with a Tiger release, then the window is refreshed correctly.

I have managed to recreate this on x86/Linux and a colleague (Peter Kessler) also recreated it on SPARC/Solaris and x86/Windows. We have hit this with recent Mustang builds (e.g., b80).

EVALUATION The test case is failing because it's drawing directly to the screen. In 1.6 we changed Swing's painting model such that all painting is done to an offscreen buffer per window. When the window is exposed we no longer generate a paint event, instead we copy directly from the offscreen buffer. This is causing problems with the test case as it renders directly to the screen, so that when we get an expose event and copy from the offscreen buffer it has the wrong thing. This was a known limitation of buffer per window and listed in the CCC request. None-the-less as at least one person is encountering the bug, it's worth considering a workaround. One idea is to override getGraphics in Swing's top level components. If someone other than Swing invokes this method, disable buffer per window, so that the expose event will generate a paint event and all will be well. Painful, but it should work.