JDK-4798194 : fullscreen apps hang on Matrox g400 running win2k
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.2
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_nt
  • CPU: x86
  • Submitted: 2002-12-30
  • Updated: 2003-01-06
  • Resolved: 2003-01-06
Related Reports
Duplicate :  
JDK-4738111 - java crashes or hangs when display mode changes on Matrox g400 (Windows only)
Description
Run the attached test case, SetDM.java, on the latest mantis builds with a 
win2k machine that has a Matrox g400 card.  This bug is demonstrated
easily using the latest Matrox drivers.

The application is quite simple; it runs in fullscreen mode, changes the
display resolution, and should paint the window red.  What actuallyh
occurs is that the window stays blank and you cannot alt-tab out of the
application to quit it.  The only way to quit the app is to run the
Task Manager and kill the java process.
Comments
EVALUATION The problem is in the pixelFormat code. Apparently the matrox driver has a problem with the pixelFormat routines when an application is in fullscreen mode. The is probably because the pix fmt functions rely on OpenGL functionality, which is possibly in conflict with ddraw during fullscreen mode. The error I see is as follows: - After a display mode switch, we get the WM_DISPLAYCHANGED event - We propagate this event to all graphics devices - Each graphics device makes a call to a native method to retrieve the default pixel format ID for that device - This native function calls ChoosePixelFormat() (a win32 API that is somehow connected to OpenGL functionality) - This call never returns. While it sits there, I can see debug output (from enabling debug output in the DirectX debug libraries) in my DevStudio debugger that shows a couple of strange things: - The matrox drivers is trying to initialize the device, the same as it did when we first called DirectDrawCreate() - The matrox driver then tries to create the primary surface and complains that it cannot do so because it does not have exclusive ownership of the device. - It continues to attempt the primary creation over and over, thus hanging itself in an infinite loop. Presumably, this hang in the driver prevents further normal processing in the application and OS, thus requiring the user to kill the process to get back to the desktop. I think the fix for this is simple: just avoid setting the default PixFmtID. A fix was made to the graphics device code recently that did this for the non- fullscreen case; we actually do not need pixel format info for most applications, but applications are free to call methods that retrieve that info if they actually do need it. I think that this previous fix probably just neglected to remove that call from the displayChanged code; there should be no reason that we need that info after a display change if we didn't need it when running the app normally. I want to verify this with the engineer that implemented the original fix... ###@###.### 2002-12-30 This hang bug is caused by the same problem that causes java apps to crash running on older Matrox drivers when display mode setting is performed (bug 4738111). In this previously-filed bug, an app mysteriously exits when either it or another application sets the display mode. The problem is the same as in bug 4798194; we are trying to perform OpenGL-related pixel-format functionality while a DirectX app has fullscreen-exclusive control over the display (either our own app or another app, such as a screen saver). The problem is the same, the consequence depends on your matrox driver version; older drivers cause our Java app to quietly exit, newer drivers cause our app to hang in the ChoosePixelFormat call. Closing this bug as a duplicate of that older bug. ###@###.### 2003-01-06
06-01-2003