In one sense, BitBlt is a superset of PatBlt. It does everything PatBlt does but also introduces a second device context into the logical operation. Here's the general syntax:
BitBlt (hdcDest, xDest, yDest, xWidth, yHeight,
hdcSrc, xSrc, ySrc, dwROP) ;
The BitBlt call modifies the destination device context (whose handle is hdcDest) within the rectangle defined by the logical point (xDest, yDest) and the xWidth and yHeight parameters, both of which are in logical units. These parameters define a rectangle as described in the previous section. BitBlt also uses a rectangle in a source device context (whose handle is SrcDC). This rectangle begins at the logical point (xSrc, ySrc) and is also xWidth logical units wide and yHeight logical units high.
BitBlt performs a logical combination of three elements: the brush selected in the destination device context, the pixels in the source device context rectangle, and the pixels in the destination device context rectangle. The result is written to the destination device context rectangle. You can use any of the 256 ROP codes for the dwROP parameter to BitBlt. The 15 ROP codes that have names are shown in the table below. If you need to use any of the others, you can look them up in the Programmer's Reference.
| Pattern (P): | 1 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | |||
| Source (S): | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | Boolean | ROP | |
| Destination (D): | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | Operation | Code | Name |
| Result: | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 000042 | BLACKNESS |
| 0 | 0 | 0 | 1 | 0 | 0 | 0 | 1 | ~ (S|D) | 1100A6 | NOTSRCERASE | |
| 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | ~ S | 330008 | NOTSRCCOPY | |
| 0 | 1 | 0 | 0 | 0 | 1 | 0 | 0 | S & ~D | 440328 | SRCERASE | |
| 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | ~D | 550009 | DSTINVERT | |
| 0 | 1 | 0 | 1 | 1 | 0 | 1 | 0 | P ^ D | 5A0049 | PATINVERT | |
| 0 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | S ^ D | 660046 | SRCINVERT | |
| 1 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | S & D | 8800C6 | SRCAND | |
| 1 | 0 | 1 | 1 | 1 | 0 | 1 | 1 | ~S|D | BB0226 | MERGEPAINT | |
| 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | P & S | C000CA | MERGECOPY | |
| 1 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | S | CC0020 | SRCCOPY | |
| 1 | 1 | 1 | 0 | 1 | 1 | 1 | 0 | S|D | EE0086 | SRCPAINT | |
| 1 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | P | F00021 | PATCOPY | |
| 1 | 1 | 1 | 1 | 1 | 0 | 1 | 1 | P|~S|D | FB0A09 | PATPAINT | |
| 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | FF0062 | WHITENESS |
Look at the eight 0's and 1's that show the result of the logical combination. The two-digit hexadecimal number that corresponds to these bits is the high word of the ROP code. If we can create a table of the result we want from the pattern, source, and destination, we can easily determine the ROP code from the table of ROP codes in the Programmer's Reference. We'll be doing this a little later. If you use 1 of the 16 ROP codes shown in the table on page 617, then you can use PatBlt instead of BitBlt, because you're not referencing a source device context.
You can set hdcSrc and hdcDest to the same device context handle, in which case BitBlt will perform a logical combination of the destination rectangle, the source rectangle, and the current brush selected in the device context. However, it's a little risky to do this in your client-area device context. If part of the source rectangle is covered by another window, then Windows will use the pixels of this other window as the source. Windows doesn't know what's underneath that other window in your client area.
However, examples of the BitBlt function using the same device context for the source and destination are the easiest to grasp. The function:
BitBlt (hdc, 100, 0, 50, 100, hdc, 0, 0, SRCCOPY) ;
copies the rectangle beginning at logical point (0, 0) that is 50 logical units wide and 100 logical units high to the rectangular area beginning at the logical point (100, 0).