JDK-4908246 : The fullscreen appls fails on win2003
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.2_02,1.4.2_06
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_2003
  • CPU: generic,x86
  • Submitted: 2003-08-18
  • Updated: 2005-11-03
  • Resolved: 2003-11-04
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.
Other
1.4.2_07 b01Fixed
Related Reports
Duplicate :  
JDK-5095232 - Test4796630 fails on win2003 while passes with Win XP and win 2000 Pro
Relates :  
JDK-4796630 - REGRESSION: fullscreen apps crash on NT4 and win98
Description
Exception is thrown while run the fullscreen test on win2003 with jdk1.4.2_02-b01

Steps to reproduce:
1. Install jdk1.4.2_02-b01 on Win2003 from /net/koori.sfbay/p/v10/jdk/1.4.2_02/ea/b01/bundles/windows-i586
2. Run the fullscreen test:
test/java/awt/FullScreen/MultiBufferDuke/MultiBufferDuke.java

The exception is thrown as follow:
Exception in thread "main" java.lang.InternalError: Could not get display modes
        at sun.awt.Win32GraphicsDevice.enumDisplayModes(Native Method)
        at sun.awt.Win32GraphicsDevice.getDisplayModes(Win32GraphicsDevice.java: 335)
        at ChooseDisplay.<init>(MultiBufferDuke.java:80)
        at MultiBufferDuke.main(MultiBufferDuke.java:399)

System info
------------
machine name: urt-08 (Dell)
OS: Windows 2003 EE
Video card: RAGE 128 PRO Ultra GL AGP
Processor: Intel Pentium 4 CPU 1.80 GHz

The same test was failed on ADM64 machine with jdk1.4.2_02b02, 1.4.2FCS, and jdk1.4.2_01b06
Machine name: urt-amd-3
OS: Window 2003 


###@###.### 2003-09-11
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_07 tiger-beta FIXED IN: 1.4.2_07 tiger-beta INTEGRATED IN: 1.4.2_07 tiger-b28 tiger-beta
17-09-2004
EVALUATION The bug is reproducible with the latest tiger build on amd64 windows 2003 server ###@###.### 2003-10-16 It's not clear to me which problem is reproducible on the latest 1.5 builds. From my testing, it looks like the failure that this bug was submitted under (not being able to ge the display mode) was fixed in b15 of 1.5 (and thus this bug is a duplicate of bug 4855214). However, the app still fails under 1.5 (and 1.4) due to something completely unrelated; the app allows you to choose a display mode and then goes into fullscreen mode, but thereafter you get only a blank (possibly white or blue) screen. Notes about this new (to me) failure: - the failure is reproducible on other (non-win2003) systems by simply using the -Dsun.java2d.noddraw flag with MultiBufferDuke - I did not encounter the stack trace outlined in the "Work Around" section - The current failure seems to be caused by a problem with FlipBufferStrategy; the application requests a bufferStrategy and then proceeds to render to and copy from the back buffer of that strategy. The strategy returned is a FlipBufferStrategy; but in the win2003 case (where the video driver is probably unaccelerated) and the noddraw case, this FlipBS creation should fail and the app should get a BlitBufferStrategy instead. When the FlipBS is used, the rendering operations to the back buffer appear to work, but the copy from that buffer appear to be noop'd. More investigation is necessary, but I think the main bug lies in failing correctly during createBufferStrategy and returning back a BufferStrategy that will actually function when DirectX acceleration is unavailable. - See bug report 4855214 for more details on win2003; the default graphics drivers appear to be completely unaccelerated, thus running noddraw on other Windows OSs is pretty equivalent to running with no flags on win2003. We need to fix the main problem I am seeing incorrectness of createBufferStrategy in unaccelerated cases), but I need more details from the submitter on what the actual problem is that they are seeing; is it as described in the Description (which was submitted against 1.4.* and should actually be fixed in 1.5) or is it the problem I describe above? I am marking the bug incomplete pending this further information. ###@###.### 2003-10-20 The fix for the problem I am seeing in 1.5 (and earlier releases with noddraw set) is checking correctly for fullscreen/exclusive capability. Specifically, the method WComponentPeer.createBuffers() throws an exception when the system is not able to create a double-buffered (flipping) window. This is correct behavior (at least in theory): when it throws that exception, the caller of that function will then fallback to creating a BlitBufferStrategy. The problem is in the implementation of that fullscreen-check; the function WComponentPeer.isFullscreen() checks only whether the given peer window is the same as the fullscreen window currently set in GraphicsDevice. But since GraphicsDevice will emulate fullscreen capability when fullscreen-exclusive is not available, this check does not guarantee that we are actually in fullscreen-exclusive mode; only that we have a "fullscreen" window (actual or emulated). The fix here is to ensure that we are actually in hw-supported fullscreen-exclusive mode, which can be done by ensuring the current fullscreen window check as well as a check that ddraw is enabled on that graphics device. Once we plug in that check as well, the system correctly throws an exception, creates a BlitBufferStrategy, and MultiBufferDuke renders correctly. I am still leaving the bug incomplete for now, pending further info from the submitter on exactly what problem they saw with recent 1.5 builds. ###@###.### 2003-10-21 The stack trace in the "Work Around" section can be reproduced on an AMD64 windows 2003. It can be reproduced without any flags. Just run java MultiBufferDuke. It first display a pull down menu to select resolution. Pick up one, then it goes to a blank white full screen. Click the mouse on the screen. It exit full screen mode and throw exception. The topmost of the stack is something about width 0 and height 0. This could be a new bug and could be due to AMD64 architecture. ###@###.### 2003-10-23 Looks like all the problems are fixed then: - the "Could not get display modes" exception described in the Description field is fixed as of b5 of 1.5 - the blank screen problem is fixed as detailed above (make createBufferStrategy create an appropriate buffer strategy when ddraw is not available) - the stack trace in the Workaround section only occurs as fallout of the createBufferStrategy problem; with the fix outlined above neither of these problems occur. ###@###.### 2003-10-23
23-10-2003
WORK AROUND The failure was verified with flag "-Dsun.java2d.noddraw=true" from the bug #4855214 and here is a result: 1. Now you can get the "Choose Display Mode" window to select diff resolutions from the drop down menu. Without this flag the exception was thrown right way. 2. The Duke isn't loaded as expected but the exception is thrown after selecting a resolution as follow: Exception in thread "main" java.lang.IllegalArgumentException: Width (0) and height (0) cannot be <= 0 at java.awt.image.DirectColorModel.createCompatibleWritableRaster(DirectColorModel.java:999) at sun.awt.Win32GraphicsConfig.createCompatibleImage(Win32GraphicsConfig.java:120) at sun.awt.image.SunVolatileImage.getBufferedImage(SunVolatileImage.java:216) at sun.awt.image.SunVolatileImage.getSurfaceDataSw(SunVolatileImage.java:122) at sun.awt.image.SunVolatileImage.<init>(SunVolatileImage.java:89) at sun.awt.windows.WVolatileImage.<init>(WVolatileImage.java:72) at sun.awt.windows.Win32BackBuffer.<init>(Win32BackBuffer.java:20) at sun.awt.windows.WComponentPeer.createBackBuffer(WComponentPeer.java:734) at sun.awt.windows.WComponentPeer.replaceSurfaceData(WComponentPeer.java:324) at sun.awt.windows.WComponentPeer.setBounds(WComponentPeer.java:133) at java.awt.Component.reshape(Component.java:1705) at java.awt.Component.setBounds(Component.java:1664) at java.awt.Component.setBounds(Component.java:1786) at java.awt.GraphicsDevice.setFullScreenWindow(GraphicsDevice.java:198) at sun.awt.Win32GraphicsDevice.setFullScreenWindow(Win32GraphicsDevice.java:261) at MultiBufferDuke.start(MultiBufferDuke.java:233) at MultiBufferDuke.main(MultiBufferDuke.java:392) ###@###.### 2003-09-15
15-09-2003