JDK-4345586 : Rendering incorrect after switching display modes (win32 only)
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.0
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_98,windows_nt
  • CPU: generic,x86
  • Submitted: 2000-06-14
  • Updated: 2000-10-07
  • Resolved: 2000-09-25
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.0 betaFixed
Related Reports
Duplicate :  
JDK-4348489 - Win32: DitherTest leaves garbage on the screen when colors switched from 16 to 8
Relates :  
JDK-4366691 - deadlock condition on win32 during display mode switch
Relates :  
JDK-4351377 - crash in screen rendering on MT apps on win32 after display mode switch
Relates :  
JDK-4366799 - colormap sometimes wrong in 8-bit display mode (win32 only)
Relates :  
JDK-4366698 - possible deadlock on Peer object on win32 during display mode switch
Description
To reproduce this bug:

Run the Dithering demo on 256 color on win98, then switch the color to any other higher color depth, for example 16, 24, 32 bit color depth. You will see the images on the canvases be messed up totally. This does not happen on winNT.

Run the test on 16 bit or higher color depth, then switch it to 256 color, you will see the color on the dithering canvas shows as different shapes, which is unacceptable. But by resizing the dithering frame, the dithering images will repaint and work fine. This does happen on winNT.

This bug did not happen on kestrel, so it is a regression.


------------------------

I've just updated the Synopsis of this bug to better reflect the actual
problem.  The original bug described a problem when switching from 8-bit
mode to any other display mode.  However, the problem is not tied to
8-bit mode, but instead to every mode.  The real problem is that we do not
currently account for display switches in our code, so the rendering result
after a display mode switch is unpredictable (but generally incorrect).
There are several contributing factors behind this problem which have
all been filed as bugs and listed in the See Also area of this bug report.

chet.haase@Eng 2000-09-11
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin-beta FIXED IN: merlin-beta INTEGRATED IN: merlin-beta VERIFIED IN: merlin-beta
14-06-2004
PUBLIC COMMENTS This bug is fixed in display mode 16 bit or higher. There is still a problem switching between 8-bit mode, but this is filed as a separate bug (4366799). --Jeanne
10-06-2004
EVALUATION There are several problems contributing to display switches not being handled correctly in win32, but the core problem involved with this bug report (rendering being incorrect, screen garbage, etc.), is in the way that we handle rendering surfaces in Merlin. Merlin has SurfaceData objects that are used to receive the rendered pixels. These surfaces can be offscreen (in the case of BufferedImage or VolatileImage objects) or onscreen (in the case of a Component or window). The rendering artifacts described in this bug report are due to the way that we create the SurfaceData objects. At creation time (i.e., when the window or offscreen image is created), we examine the color depth of the destination (i.e., the screen or offscreen area where we create the surface). We use this color information to create a ColorModel for the SurfaceData. That ColorModel, and associated data, is used later in rendering routines such as the Blit calls that copy data from surface to surface. When the display mode is switched (by the user or by some other app), these SurfaceData objects are not notified of the change and thus use the same data that they were created with. So, for example, when we copy from a given BufferedImage of 32-bit depth onto a screen which is now 16-bits deep (but which uses a SurfaceData that was created when the screen was 32-bits deep), we will use a Blit routine that assumes a destination depth of 32-bits, and we will thus get incorrect colors and incorrect widths as we copy the pixels. The best way to fix this problem is to recreate the SurfaceData objects when the display is changed. These new version of the objects will use the updated display information and will thus have ColorModels (and other data) that is correct for the updated state of the screen (and offscreen). Fixing this problem runs into various other bugs in the code which have been described in the See Also bugs. But once those problems are ironed out, this solution appears to work. -------------------- After deadlock bugs were fixed (4366691 and 4366698), this bug was shown to be fixed. The solution was as described above: recreate the surfaceData objects after the display has changed using the new color depth information. There is still a problem switching to 8-bit mode, but this is a separate issue filed as a separate bug (4366799). chet.haase@Eng 2000-09-25
25-09-2000