Win98: DrawLineTest: the background switches black/white.
Comments
EVALUATION
Win98 is not supported platform anymore.
14-07-2010
WORK AROUND
The application currently sets the display mode and then immediately starts
rendering. there are two things that the application could do to work around
the problem:
- wait (Thread.sleep()) for some time to be sure that the display mode
switch has actually happened before creating the back buffers. This would
ensure that the back buffers get created under the correct display mode
and would thus be filled with the correct color upon creation.
- fill the buffer with a background color before drawing the line, thus
ensuring that the specified color would be used, instead of depending on
the default color used when an image is first created.
11-06-2004
EVALUATION
Committing to mantis.
###@###.### 2002-05-22
From the brief description, I assume this bug is talking about the problem
I have seen where the background color of the back buffer is sometimes
not the white color that we expect. I have seen it be black as well as
cyan.
The problem comes from two distinct situations:
- Our multithreaded approach to fullscreen and DirectX rendering means that
we call setDisplayMode() and then we create the back buffers, which can
result in the back buffers being created under the wrong (old) display mode
and then re-created under the new display mode once the display mode switch
has actually occurred. If things actually happened in the sequence that
they are laid out in the app, then we would only create the back buffers
once, in the correct (new) display mode, and the default image color would
be used to fill those buffers before rendering takes place.
- There is currently a hole in our surface restoration policy. When we
first create an image, we create it with a default color; either the
components background color or white (in that priority order). However,
when a surface is lost and restored, we do nothing to fill in the buffer
with a default color. So in the case of this app, the buffer is first
filled with the default color (white), then the buffers are lost and
recreated, then we proceed with rendering. In the meantime, the contents of
the buffer have been polluted and are unpredictable.
The fix for this seems to be to fill the buffer with some default color
upon restoration to properly restore it to a default state before the
user starts using it again. It does not seem to be the responsibility of
VolatileImage to do that task; the semantics of surface loss are clear
that the contents are unpredictable and need to be reconstituted by the
client of that image. Therefore, we should probably take care of this at
the level of the Buffer manager (the appropriate BufferStrategy object).
Upon surface restoration or recreation, we should probably fill the buffer
with some default color.
However, this seems to be a situation where the app should take on more
responsibility; to depend upon some default state of the back buffers when
the app is forcing the destruction and recreation of objects via switching
the display mode is a bit much. A well-behaved app would simply render
the graphics that they wanted into the buffer without expecting certain
results from the underlying software under these conditions (see the
Workaround section of the bug). I am therefore reducing the priority of
this bug since the workaround is easy, obvious, and probably a Good Thing To
Do in any case.
###@###.### 2002-08-27