The information in this article applies to:
SUMMARYPerforming any bitwise logical operator on a color, such as inversion, does not modify the color's RGB value; it instead changes the index into the system palette. This applies also to the ROP codes associated with the blt functions (BitBlt, StretchBlt, and PatBlt) and in the SetRop2 function. For display devices with hardware palettes [generally, devices with fewer than 24 Bits-Per-Pixel (BPP)], this can produce unexpected or undesirable results. MORE INFORMATIONSuppose the system palette contained the following colors:
The inversion of colors would look like this:
(Half = half intensity, Full = full intensity)
This obviously is not the desired effect. Inverting a full-intensity
color such as red will not invert to full-intensity cyan; instead, it
is inverted to half-intensity cyan.
This is also true for any logical operations performed on the bits of a bitmap, pen, or flood fill through ROP codes. All operations are done on the index of the color and not its RGB value. Note that when using custom palettes on a palette capable device, the application does not have control over the precise mapping between logical palette indexes and system palette indexes. The results of bitwise logical operations are unpredictable in such a case. The only way for an application to precisely control color mixing is to perform the operation on RGB values, then translate the RGB result back into the most appropriate palette index. For example, one way to do this is to mix colors in a 24 BPP Device-Independent Bitmap (DIB), then set the DIB bits into the Device Context (DC) again when finished. Another method is to query the RGB color of pixels to modify, do the mixing, and then use the SetPixel function to apply the change to the DC. Additional query words: 3.00 3.10 3.50 4.00 win16sdk
Keywords : kbNTOS350 kbNTOS351 kbNTOS400 kbWinOS95 kbSDKWin16 |
Last Reviewed: June 21, 1999 © 2000 Microsoft Corporation. All rights reserved. Terms of Use. |