JDK-6430607 : REG:Specifying BIT_DEPTH_MULTI in the display mode reduces the fullscreen size to DM's width, height
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 6
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-05-25
  • Updated: 2008-02-06
  • Resolved: 2006-08-10
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 b95Fixed
Related Reports
Relates :  
JDK-4782458 - Wrong exception is thrown while trying to set a Null or invalid Display mode
Relates :  
JDK-5094347 - clarify GraphicsDevice.setDisplayMode() spec regarding BIT_DEPTH_MULTI
Description
I am obtaining all the display modes from the default screen device. I have replaced the bit depth value with BIT_DEPTH_MULTI and setting this display mode object to the graphics device, after pushing a frame into FS mode. This makes the fullscreen appear small and the frame is no longer FullScreen. Say if the display mode is 640, 480 then the fullscreen size reduces to 640, 480 and the desktop's display mode is retained.

This is noticed since Mustang-b51 and not reproducible on b50. This is not reproducible on Tiger-FCS. This is noticed only on ddraw. On noddraw and OGL, this throws an exception saying 'invalid display mode'. Hence this is a regression introduced in Mustang-b51.

I have attached a sample test. Execute the sample test. A FS frame would appear with a button. Label of the button would show the display mode to be set. The bit depth value will be shown as '-1'. Click the button. If the frame's size reduces to the display mode's width and height, the bug is reproduced.
Comments
SUGGESTED FIX http://javaweb.sfbay/jcg/1.6.0-mustang/2D/6430607/
27-07-2006
EVALUATION The doc changes will be handled under different bug id, 5094347. A CCC request has been filed for it.
26-07-2006
EVALUATION We have also decided to clarify the wording around the use of BIT_DEPTH_MULTI, and some other things.
31-05-2006
EVALUATION Actually, this is not a regression in mustang. The test doesn't behave correctly even before b51, it just behaves incorrectly in a different way. GD.setDisplayMode() should throw InvalidPipeException if "if the DisplayMode supplied is null, or is not available in the array returned by getDisplayModes", with the exception of a display mode with REFRESH_RATE_UNKNOWN, which means "any refresh rate". It doesn't throw this exception in b50, but tries to set this invalid display mode and silently fails. In b51 there were some changes which adjusted the size of the fullscreen window according to the display mode set. And since the setDispalyMode() fails silently, the window is just resized to the dimensions of the mode to be set. Now the reason why setDisplayMode doesn't throw the exception is the code in DXObject::EnumDisplayModes: if (dm->bitDepth != java_awt_DisplayMode_BIT_DEPTH_MULTI) { ddsd.dwFlags |= DDSD_PIXELFORMAT; ddsd.ddpfPixelFormat.dwFlags = DDPF_RGB; ddsd.ddpfPixelFormat.dwSize = sizeof(DDPIXELFORMAT); ddsd.ddpfPixelFormat.dwRGBBitCount = dm->bitDepth; } if (dm->refreshRate != java_awt_DisplayMode_REFRESH_RATE_UNKNOWN) { ddsd.dwFlags |= DDSD_REFRESHRATE; ddsd.dwRefreshRate = dm->refreshRate; } This code was added as part of the tiger fix for 4782458 Wrong exception is thrown while trying to set a Null or invalid Display mode From the evaluation of that bug it sounds like it was assumed that BIT_DEPTH_MULTI value for the dm depth meant "any depth", which is actually not the case. We should just pass the requested bit depth (-1 for MULTI) to ddraw and let it reject the incorrect mode, which it happily does.
25-05-2006