In a multi-display system where the primary display is in 32-bit mode and all
other displays are in 8-bit gray mode (non-palettized, linear), the display
driver provides DrvBitBlt that will convert 32/24-bit source to 8-bit
destination using NTSC weighting. Most drawing to the displays goes, as
expected, through DrvBitBlt. However, not all code path seemed to go through
that. Specifically, clicking the right mouse button on an 8-bit display and
then selecting "Refresh" leaves a rectangular region that is rendered
differently, using Windows' own way of converting 32/24-bit to 8-bit.
Similar artifacts show up when pop-up descriptions pop down in the main file
area of the windows explorer. Interestingly, the pop-up descriptions popping
up for items on the left area (system Tasks, Other Places), do not leave any
artifacts. How can one avoid those artifacts? Is there a way to provide
this NTSC weighting to Windows to be used for all 32/24-bit to 8-bit
conversions (XlatOBJ, PalOBJ)?

There could be other reasons for these artifacts. Does this ever happen in
just single monitor display?

differently

Is this rectagular region in the area that was where the menu was after the
right click? The image to replace the menu may have come through CopyBits
from a cached bitmap.

This posting is provided "AS IS" with no warranties, and confers no rights.

ATS8 wrote:
Yes, I've seen problems with that setup too. Currently our work around
is to advise our users not to run in 8-bit mode.

Tim.