JDK-4366708 : ColorModel calculated incorrectly after display mode switch (win32 only)
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.0
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_nt
  • CPU: x86
  • Submitted: 2000-08-29
  • Updated: 2001-06-26
  • Resolved: 2001-06-26
Related Reports
Relates :  
JDK-4348489 - Win32: DitherTest leaves garbage on the screen when colors switched from 16 to 8
Description
On Windows, when the display mode is changed (e.g., the user changes it
via the Display Settings dialog), awt sometimes returns an incorrectly
created ColorModel object, either using bogus display values or values from
the previous display settings.  this results in incorrect colors and incorrect
sizes (due to bad pixel size assumptions) being painted to the screen.

This bug is one of the factors contributing to bug #4348489.
Comments
EVALUATION There are a couple of different problems in the awt code contributing to this bug: - AwtImage::InitializePalette() does more than init the palette. Some of the functionality of that method is required on every display mode change, but the method is currently only called if/when the palette is not yet initialized. The logic in the WM_DISPLAYCHANGE case of awt_Toolkit.cpp must change to call both the recurring changes necessary and the initialization changes necessary (but only if we actually need a palette; if we just changed from 32-bit mode to 16-bit mode there's no need to init a palette). - Java_sun_awt_Win32GraphicsConfig_makeColorModel() currently uses the pixel format ID (AwtWin32GraphicsConfig::win32GCVisualID) if available to construct the ColorModel. The approach doesn't work in all cases: - If the app is running on non-NT windows, then opengl32.dll is not necessarily loaded (unless we're inside of java3d) and thus the visualID will be null (an undocumented but nifty feature of the win32 API). This actually works fine for us since we then default to using the AwtImage::getColorModel() which works in all cases. But this approach is not consistent and we should have the same method of producing the ColorModel on all platforms/situations. - When the visualID is not null, the structure filled in by ::DescribePixelFormat() is sometimes wrong after a display mode switch. This seems to be platform/video-driver specific, but is flaky enough that we should find a different solution for base graphics services such as ColorModel. chet.haase@Eng 2000-08-29 I suspect that these problems are now solved: the AwtImage::InitializePalette() call has been removed altogether, as has Java_sun_awt_Win32GraphicsConfig_makeColorModel(). Contacted submitter - awaiting confirmation that this bug is no longer an issue. brent.christian@eng 2001-06-26 Yup - this was fixed at some point by 2D. brent.christian@eng 2001-06-26
26-06-2001