JDK-6245358 : PIT: OGL:ClassCastException thrown with OGL while disabling the HW acceleration at runtime, WinXP
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 6
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2005-03-24
  • Updated: 2012-01-16
Related Reports
Relates :  
JDK-6532818 - OGL: VM Crash when launching a test that changes display mode, Win32
Relates :  
JDK-6319746 - PIT:OGL: VM crash when changing the display mode from 32 bit to 8 bit programmatically, Win32
Relates :  
JDK-6244071 - PIT: OGL: Swing is broken on OpenGL pipeline with the gray rect fix, Win32
Description
I am running one of the demos (Java2Demo / SwingSet2) with OpenGL flag on WinXP using the following Swing PIT build:
java version "swing-jcg-win-03-2005-03-23-int.mustang"
Java(TM) 2 Runtime Environment, Standard Edition (build swing-jcg-win-03-2005-03-23-int.mustang)
Java HotSpot(TM) Client VM (build 1.6.0-ea-b28, mixed mode)

OpenGL is enabled since I am using NVidia GeForce4 MX4000 video card. When the application is running, I am opening the display panel and disabling the hardware acceleration and clicking 'Apply'. Once i do this, I am seeing lot of ClassCastExceptions on the console, thrown repeatedly. 

This is not reproducible with the latest promoted build - Mustang-b28. This is not reproducible without opengl, works fine on the current PIT build as well as earlier promoted builds. This is reproducible on the original Swing PIT build dated 19.Mar.2005 (which does not have the fix for-6244071) as well as on the Re-spin dated 24.Mar.2004. I think this is caused by the GrayRect fix.

Here is the exception from SwingSet2:

Exception in thread "AWT-Windows" java.lang.ClassCastException: sun.awt.Win32GraphicsConfig cannot be cast to sun.java2d.opengl.WGLGraphicsConfig
at sun.java2d.opengl.WGLVolatileSurfaceManager.initAcceleratedSurface(WGLVolatileSurfaceManager.java:64)
at sun.awt.image.VolatileSurfaceManager.validate(VolatileSurfaceManager.java:146)
at sun.awt.image.SunVolatileImage.validate(SunVolatileImage.java:225)
at java.awt.Component$BltBufferStrategy.revalidate(Component.java:3771)
at java.awt.Component$BltSubRegionBufferStrategy.validateAndShow(Component.java:3863)
at javax.swing.BufferStrategyPaintManager.show(BufferStrategyPaintManager.java:243)
at javax.swing.RepaintManager.show(RepaintManager.java:1109)
at javax.swing.SwingPaintEventDispatcher.createPaintEvent(SwingPaintEventDispatcher.java:43)
at sun.awt.windows.WComponentPeer.postPaintIfNecessary(WComponentPeer.java:625)
at sun.awt.windows.WComponentPeer.handleExpose(WComponentPeer.java:609)
at sun.awt.windows.WToolkit.eventLoop(Native Method)
at sun.awt.windows.WToolkit.run(WToolkit.java:270)
at java.lang.Thread.run(Thread.java:595)
###@###.### 2005-03-24 05:28:05 GMT
Comments
EVALUATION The problem is that disabling acceleration (using the Display properties tab) at runtime will cause us to reinitialize the default GraphicsConfig. If the app starts up with OGL enabled, its default GraphicsConfig will be a WGLGraphicsConfig. Apparently when you disable acceleration entirely, it means we can't initialize the OGL pipeline, so at runtime the default GraphicsConfig will become a plain Win32GraphicsConfig (and presumably we'll fall back on our GDI-based pipeline). The issue here is that when the Swing backbuffer is created, we create a SunVolatileImage, and then we create a WGLVolatileSurfaceManager for that SVI. Then we should get a displayChanged() event after the display properties are changed by the user. In the WGLVSM.displayChanged() we call vImg.updateGraphicsConfig() so that the SVI's GraphicsConfig will be a Win32GraphicsConfig. The problem is that we don't actually replace the VSM used by the SVI. So when we try to recreate the accelerated surface in initAcceleratedSurface(), we assume that vImg.getGraphicsConfig() will return a WGLGraphicsConfig, but in fact it will return a Win32GraphicsConfig, and therefore we see the ClassCastException. The fix should be along the lines of replacing (or reinitializing) the VSM used by the SVI after a display change event. It seems that this problem might affect managed images as well... I'm not sure why this is only reproducible with bufferPerWindow=true; perhaps in the bufferPerWindow=false case, Swing will recreate the VolatileImage after a display change? ###@###.### 2005-03-24 22:24:24 GMT
24-03-2005
WORK AROUND Pass in -Dswing.bufferPerWindow=false ... ###@###.### 2005-03-24 22:24:24 GMT
24-03-2005