How does bit blit work in GDI?

Question

I'm interested in how bit blit works in gdi. I know that that it creates a resulting bitmap based on source and destination bitmaps based on dwROP parametar, but I'm interested how? I saw some example in which it is used for masking that is done with monochrome mask and SetBkColor() function, I am really confused how is BkColor related to these bitmaps... And in the other one, SetTextColor() is used, for removing the background... How are these DC attributes (bkColor and textColor) related? Thanks

Answer 1

You are wrong BitBlt never uses text for background color. BitBlt raster operations use a pattern (that's the current selected brush), the source and destination bitmap.

The dwRop code defines a calculation between this 3 data sources.

You find a good explanation how this rop codes work in the book of Charles Petzold. Here is a corresponding chapter of the book. Read the part "The Raster Operations".

Answer 2

Background and text color don't play a role, only the current brush that's selected in the destination device context.

BitBlt() iterates through the pixels in the source rectangle and copies the pixels after applying a mathematical operation on the pixel data. The dwRop value determines that operation. There are three pixel values that are combined by the operation to calculate the pixel value of the destination bitmap:

• the pixel from the source bitmap. The ROP code identifier contains "SRC".
• the pixel from the brush. The ROP code identifier contains "PAT" if used.
• the pixel from the destination bitmap before it is written, you'll see "DST" if used.

The mathematical operation applied to the pixel value are very simple. They can be

• none, dwROP = SRCCOPY or PATCOPY.
• always set to 0, dwROP = BLACKNESS
• always set to 1, dwROP = WHITENESS
• NOT operator, same as ~ in a C program
• AND operator, same as & in a C program
• OR operator, same as | in a C program
• XOR operator, same as ^ in a C program

These operations are so simple because that's what a processor can easily do. And they are very simple to accelerate in hardware. The most important thing to keep in mind is that they are bit operators, the operation is applied to each individual bit in the pixel value. That makes ROPs an historical artifact, they only have a useful outcome on monochrome bitmaps (1 pixel = 1 bit) or indexed bitmap formats, like 4bpp or 8bpp, with a carefully chosen palette. That mattered on machines in the 1980s.

The kind of video adapters you use today, as well as bitmap formats, are at least 16bpp, almost always 24bpp or 32bpp. An operation like NOT on a pixel of such a bitmap just produces a wildly different color that the human eye isn't going to recognize as in any way related to the original color. Today you only use SRCCOPY. Maybe PATCOPY to apply a texture brush, you'd use PatBlt() instead. There's hackorama with multiple BitBlts to create transparency effects, you'd use TransBlt() or GDI+ instead.