Bug ID: JDK-4690085 Color problems in fullscreen mode

Type: Bug
Component: client-libs
Sub-Component: 2d
Affected Version: 1.4.0

Priority: P4
Status: Resolved
Resolution: Fixed
OS: windows_2000
CPU: x86

Submitted: 2002-05-22
Updated: 2002-11-05
Resolved: 2002-09-25

Other	Other
1.4.1_01 01Fixed	1.4.2Fixed

+ MultiBufferDuke has problems.  On a Windows 2000 machine with a Matrox Millenium II, a few of the display modes do not work (color problems).  From 24-bpp,  640x480x8x60 looks corrupted, as if drawing in the wrong depth, as do 800x600x8x60 and 512x384x8x85.  1024x768x8x60 flashes (strobes, really).
320x200x8x85 paints the sprite strangely, as if it's starting at the wrong memory location.

+ win98+Voodoo3, MultiBufferDuke: 8, 16 and 24 bit modes have color problems (even though the build was run locally), no matter what the desktop depth is. 32 bit is fine.

+ DukeRoids: This tends to have bad color problems.  On win2k, start in
16 bit mode. It works by default (1024x768x16).  When run with -d 32 option, colors are hosed. Run with -d 8 bad colors plus a crash when exiting.

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.1_01 mantis FIXED IN: 1.4.1_01 mantis INTEGRATED IN: 1.4.1_01 mantis mantis-b07

14-06-2004

EVALUATION Committing to mantis. ###@###.### 2002-05-22 The problem was that we were not replacing the surfaceData object at the right time. Previously, we would call setDisplayMode(), followed by replaceSurfaceData(). However, there was no way to ensure that the right stuff would happen in between these two calls to make sure that the new surfaceData would have the right color model. Specifically, when we change display modes, the dynamicColorModel of the GraphicsDevice must be recreated in the new display mode. In order for this to happen, the old one must be nulled-out by the time a request is made to the GraphicsDevice for a new one. When the colorModel is null, we cause it to be recreated, which forces us to examine the new color info for the new display mode. What used to happen is that we would set display mode, not necessarily null-out the obsolete dynamicColorModel in GraphicsDevice, then we would create our new surfaceData object. This new surfaceData object would request the dynamicColorModel, would get the reference to the obsolete object, and would then create the surfaceData with the old (incorrect) color data. At the native level, everything would be fine because DirectDraw always creates surfaces in the current display mode. But the decisions we make in our Java code hinge on the color data at the Java level, not at the native level, so we would do things like assign an incorrect scan stride, or an incorrect color value for pixels, etc. The fix is to wait until the right time to replace the surfaceData. We currently null-out the obsolete dynamicColorModel when we receive the WM_DISPLAYCHANGE event (which we receive at some indeterminate time after the display mode switch). So we should wait until after that time to replace the surfaceData object. The code change is simple; previously we would avoid propagating the display switch event in some fullscreen situations, but really we should only avoid recreating the primary. By simply moving the end-bracket of the if() clause in the WM_DISPLAYCHANGE case, we force surfaceData recreations to happen in all cases, which forces all surfaceData objects to be recreated with the new, correct colorModel information. At the same time, we should remove the old replaceSurfaceData() call; the setDisplayMode() call will force a WM_DISPLAYCHANGE event in cases where a replacement is necessary (when we have actually changed the display mode and not just set it to the one that was already active) and that, in turn, will force its own surfaceData replacement. ###@###.### 2002-08-27

27-08-2002

Duplicate :	JDK-4703340 - fullscreen window comes up in the wrong video mode
Relates :	JDK-4480734 - MultiBufferDuke crashes when changing from 8 to 16 bpp (win32 only) (multimon)