Bug ID: JDK-6290245 OGL: Swing component artifacts seen after resizing J2SE demo windows on WinXP with Mustang B40

Versions (Unresolved/Resolved/Fixed)

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 b51Fixed

With OGL pipeline, there are artifacts seen after simply resizing a window with most J2SE demos.  The Swing components will become jumbled together and the error will remain until an update is done (by iconifying or maximizing window size).

- This regression was introduced in Mustang B40 and seems to only be reproducible on Windows (using WinXP).
- The bug is reproducible with OGL pipeline on both Nvidia and ATI graphics cards.

Steps to reproduce
==================
With Mustang B40 build or later:

1) Run one of the sample J2SE demos (Font2DTest, Java2Demo, SwingSet2, etc) using the OGL flag, for example in Font2DTest directory, run the command:

..\..\..\bin\java -Dsun.java2d.opengl=True -jar Font2DTest.jar

3) After the demo launches, resize the window and observe artifacts.


###@###.### 2005-06-24 00:28:36 GMT

EVALUATION The evaluation above is accurate. During a live resize, we upcall to WComponent.dynamicallyLayoutContainer() for each WM_SIZING event. When the OGL pipeline is enabled, we should be calling replaceSurfaceData() so that the the WGLSurfaceData for the window is reinitialized with the correct bounds reflecting the current window bounds. This is not necessary when OGL is not enabled. The main problem for OGL is that the OpenGL viewport will "track" the lower-left corner of a frame on Windows when that frame is being resized. This means that even with the fix proposed above, it is still possible that by the time we go to repaint the container during a live resize, the actual window bounds may have changed since the last replaceSurfaceData() call. So at least the container will be repainted using those "last known" bounds, so things will look reasonable, but once in a while (depending on how fast the user resizes the window), you may see some "dancing", where the container is painted +/- a few pixels offset from the upper-left origin of the frame. There's not much we can do about this intermittent dancing given our current multithreaded architecture, and the fact that we always need to setup the viewport to account for Java 2D's upper-left origin. Most native OpenGL applications use the lower-left origin system, and even then, most of those apps call their "reshape" and "display" methods from the Windows event thread, so they wouldn't likely run into this same issue. I think the fix suggested above will solve 99% of the problem (you will no longer see garbage during a live resize), and this will even be much better than the behavior we saw in Tiger and in Mustang before dynamic layout was enabled by default in b40 (see 5043715 for the non-dynamic layout variant of this bug for more info).

18-08-2005

EVALUATION I saw this for the first time last week, but forgot to file the bug. I immediately suspected that it has something to do with the fact that AWT enabled dynamic layout ("live resize") by default on Windows in b40. I talked with the AWT lead and he agrees this is likely the cause of this bug. Probably we're not recreating the window's SurfaceData while the window is being resized, and then OGL gets confused because it relies on up-to-date window dimensions in order to render correctly. ###@###.### 2005-06-24 00:51:53 GMT

24-06-2005

Relates :	JDK-5043715 - OGL: Resizing a frame distorts the volatile image rendered on the frame
Relates :	JDK-6600226 - D3D: Repainting Issues while resizing a Swing application.