-
Bug
-
Resolution: Fixed
-
P3
-
1.4.0
-
None
-
beta
-
x86
-
windows_nt
Run VolatileDuke in 16 or 32-bit mode. Switch the display depth to 8-bit.
Note that the Duke image is now all black.
Note that the application runs correctly when you start in 8-bit mode,
even if you switch to another depth and then return to 8-bit mode. So
I suspect there is some colormap initialization that is happening when
starting in 8-bit mode but is not happening when we switch to that mode.
-----------------
I had originally thought that this problem was confined to VolatileImage
objects, such as are used in VolatileDuke. Also, it seemed that the problem
only resulted when the display mode switched into 8-bit mode from some
other mode.
However, the problem is much more far-reaching than that. The problem
can be reproduced by a simple app that draws text directly to the onscreen
window. In 8-bit mode, simply toggle between that app and some other
app that has its own palette (such as IE or Netscape); you should see
wrong colors being used in various drawing primitives, such as text.
I will attach a simple test program that shows off this bug fairly well.
The test is VImageColors. It consists of one onscreen window with
three sections. The left thrid is drawn using a VolatileImage back buffer.
The middle pane uses a BufferedImage back buffer. And the right pane
is drawn directly to the screen. All three panes use the same image,
same text color, and same fill color, so they should all look the same
(modulo some dithering differences in some situations).
The first problem noticeable is that the right panel uses the wrong
color for the fill and the text. This is an unrelated problem that I have
filed as 4425895.
The second problem is noticeable when toggling
the app with some other palettized app; it is clear there are various rendering
bugs preventing the colors from being correct when the app is in the
background. (the fill color is wrong in some panels, the duke image is
either badly dithered or simply wrong, and the text color is wrong in
some panels).
A third problem is seen when you start the app in the background
(run the program and then immediately bring a palettized app to the
foreground. When the window eventually comes up, it should be in the
background.) Now the colors look wrong in some of the panels both when
the app is in the background and in the foreground.
Note that the Duke image is now all black.
Note that the application runs correctly when you start in 8-bit mode,
even if you switch to another depth and then return to 8-bit mode. So
I suspect there is some colormap initialization that is happening when
starting in 8-bit mode but is not happening when we switch to that mode.
-----------------
I had originally thought that this problem was confined to VolatileImage
objects, such as are used in VolatileDuke. Also, it seemed that the problem
only resulted when the display mode switched into 8-bit mode from some
other mode.
However, the problem is much more far-reaching than that. The problem
can be reproduced by a simple app that draws text directly to the onscreen
window. In 8-bit mode, simply toggle between that app and some other
app that has its own palette (such as IE or Netscape); you should see
wrong colors being used in various drawing primitives, such as text.
I will attach a simple test program that shows off this bug fairly well.
The test is VImageColors. It consists of one onscreen window with
three sections. The left thrid is drawn using a VolatileImage back buffer.
The middle pane uses a BufferedImage back buffer. And the right pane
is drawn directly to the screen. All three panes use the same image,
same text color, and same fill color, so they should all look the same
(modulo some dithering differences in some situations).
The first problem noticeable is that the right panel uses the wrong
color for the fill and the text. This is an unrelated problem that I have
filed as 4425895.
The second problem is noticeable when toggling
the app with some other palettized app; it is clear there are various rendering
bugs preventing the colors from being correct when the app is in the
background. (the fill color is wrong in some panels, the duke image is
either badly dithered or simply wrong, and the text color is wrong in
some panels).
A third problem is seen when you start the app in the background
(run the program and then immediately bring a palettized app to the
foreground. When the window eventually comes up, it should be in the
background.) Now the colors look wrong in some of the panels both when
the app is in the background and in the foreground.
- relates to
-
JDK-4345586 Rendering incorrect after switching display modes (win32 only)
-
- Closed
-
-
JDK-4348489 Win32: DitherTest leaves garbage on the screen when colors switched from 16 to 8
-
- Closed
-
-
JDK-4280257 256 colors corrupt and flash when switch focus (win32 plugin only)
-
- Resolved
-
-
JDK-4425895 onscreen window not using correct palette on win32 8-bit mode
-
- Resolved
-