JDK-6289439 : OGL: Application hangs when changing the color depth at run time, WinXP
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 6
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2005-06-22
  • Updated: 2012-01-16
Related Reports
Relates :  
JDK-6319746 - PIT:OGL: VM crash when changing the display mode from 32 bit to 8 bit programmatically, Win32
Description
I have attached 2 tests to this bug report. Run any of them with OpenGL pipeline on WinXP with Nvidia GeForce MX4000. I am using the latest driver - 71.89 with DirectX9.0c. The application will bring up a fullscreen frame. When the application is running, click the 'Show desktop' icon on the windows toolbar. Open the display panel and change the color depth to 16bit from 32bit. Restore the application. You would see the application is not getting restored. Press CTRL + C on the console and you would see lot of NPEs thrown on the console. 

Here is the NPE: 
java.lang.NullPointerException: disposed component
at sun.java2d.opengl.OGLRenderQueue.flushBuffer(Native Method)
at  sun.java2d.opengl.OGLRenderQueue.flushBuffer(OGLRenderQueue.java:108)
at sun.java2d.opengl.OGLRenderQueue.access$300(OGLRenderQueue.java:20)
at  sun.java2d.opengl.OGLRenderQueue$QueueFlusher.run(OGLRenderQueue.java: 177)

This is reproducible atleast since Mustang-b37 till the current PIT build. Not reproducible with ddraw, noddraw. 

2 Tests attached to the bug report.
###@###.### 2005-06-22 17:36:01 GMT
Comments
EVALUATION This is also easily reproduced with any of the JDK demos (Java2Demo, etc). I looked into this a bit further with debug tracing enabled. I was able to see that after a display change, the WGLWindowSurfaceData for the heavyweight window is replaced. However, the underlying heavyweight (top-level) window is the same. When the app started up in the original display mode, that window will have had its PixelFormat set (via SetPixelFormat()) in terms of the old display mode. After the display change, when we try to initialize the WGLSurfaceData describing that window, we will attempt to set a PixelFormat corresponding to the new display mode. The problem is that it is illegal to call SetPixelFormat() more than once for the same heavyweight component. So at least we detect this error so that all further rendering is essentially no-oped; this is what gives the app the appearance that it is hanging, even though it isn't really hanging, it's just not painting anything. I'm really not sure at this point how we can fix this. Perhaps there is some way to re-create the underlying heavyweight window after a display change so that it is safe to call SetPixelFormat() for the new display mode?
24-08-2005
EVALUATION The problem appears to be in WGLSurfaceData.c in the OGLSD_InitWindow() method. If the component has been disposed, we throw an NPE. Before STR, this might have been an acceptable practice, but now I think we should probably just return JNI_FALSE as we do in other failure situations, and the rest of the code should be robust against this case. That takes care of the reported exceptions at exit, but I'm not sure yet why the app is not being restored properly after the display change (I don't see evidence though that this is a hang). ###@###.### 2005-06-23 03:54:08 GMT
23-06-2005