JDK-4902507 : double buffered X11 and GLX windows do not resize properly
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 5.0,6
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,linux
  • CPU: generic,x86
  • Submitted: 2003-08-07
  • Updated: 2006-06-27
  • Resolved: 2005-02-12
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.
JDK 6
6 b24Fixed
Related Reports
Relates :  
Description
Top level windows that use BufferStrategy (either via X11/XDBE or GLX) cannot
be resized by the user without garbage appearing in the window.

This has been a problem since 1.4.0 (when BufferStrategy and XDBE support was
added), but is now also an issue in Tiger with the OpenGL pipeline.  Various
tutorials and code samples for BufferStrategy have recommended that the
developer call setResizable(false) on a top-level that uses BufferStrategy,
but that workaround only masks this bug.  Users should most definitely be able
to resize multibuffered windows without seeing those artifacts.

I spent some time tracking down the source of the problem and peppering printf's
throughout the AWT code.  I determined that whenever a window (either single
or doublebuffered) is resized, the ConfigureNotify event is detected and
propagated correctly at the native layer.  In both cases the
MWindowPeer.handleResize() method is correctly invoked, but it appears that
in the doublebuffered case, the COMPONENT_RESIZED event is not dispatched
properly.  This means we never go into the MComponentPeer.setBounds() method
and therefore never recreate the SurfaceData and all the other stuff that
should be taking place on a window resize event.  I've seen similar behavior
with XAWT, but I did not track down the code path for XAWT (I assume it's
similar).

I think most of the work for this bug falls on the AWT side, as there are
problems with resize event notification in the multibuffered case.  However, the
fix will also most likely require changes to 2D code, in how we restore the
VolatileImage that represents the backbuffer when the window is resized.  We
will have to work together to find an appropriate fix to this issue.

Compile and run the attached testcase (XformMB.java).  Then once the frame
is realized, attempt to resize the window, and you should see very ugly and
noticeable flickering inside the window.

Comments
EVALUATION Name: ssR10077 Date: 01/19/2004 ###@###.### 2004-01-19 Looks like it's related to 4919042. ====================================================================== I checked that the fix for 4919042 doesn't fix this bug. Swing team requires this to be fixed to resolve gray-box problem, we must fix this ASAP. ###@###.### 10/5/04 11:36 GMT It appears that the fix for 4919042 did resolve the resize event problems that I had originally reported with this bug report. However, the other 2D-specific changes (detecting when the backbuffer needs to be recreated) still need to be made. As mentioned above, this needs to be fixed soon because the gray rect fix depends on this functionality, so that resizing windows using BufferStrategy works properly. Fortunately, the changes are localized to Component.java in the FlipBS and BltBS implementations. In the FlipBS case, we were not detecting the case where the window has been resized (BltBS already handled this case properly). The fix here is to add checks in FlipBS.revalidate() (similar to BltBS.revalidate()) so that we recreate the backbuffer(s) when the window has been resized. I'm taking this opportunity to clean up a few other minor problems with the BufferStrategy implementations. For example, validatedContents was never reset if it was ever set to true (such as when the underlying VolatileImage has been restored), and so contentsRestored() would always return true. The fix here is to clear the validatedContents flag at the beginning of revalidate(). Another problem: in BltBS when the backbuffers are re-created (e.g. after the component has been resized), we did not first explicitly call flush() on any existing backbuffers. Now that we are calling flush() before recreating the backbuffers, we are more likely to have VRAM available for the newly created surfaces. Another problem: in both FlipBS and BltBS we had never properly checked for IMAGE_INCOMPATIBLE in revalidate(). Now we do check for this value, and if it is returned from validate() we will recreate the backbuffers and set the validatedContents flag. With these fixes in place, the attached testcase can be resized (with the correct results) on Windows (with and without OGL) and on Solaris/Linux (with and without OGL). I'm reassigning this bug to myself, since AWT is no longer responsible for these fixes. ###@###.### 2005-1-29 01:24:16 GMT
29-01-2005