United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4902507 : double buffered X11 and GLX windows do not resize properly

Details
Type:
Bug
Submit Date:
2003-08-07
Status:
Resolved
Updated Date:
2006-06-27
Project Name:
JDK
Resolved Date:
2005-02-12
Component:
client-libs
OS:
linux,generic
Sub-Component:
2d
CPU:
x86,generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
5.0,6
Fixed Versions:

Related Reports
Relates:

Sub Tasks

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
                                     
2005-01-29



Hardware and Software, Engineered to Work Together