Bitmaps

Windows supports two main types of bitmap: Device-Independent Bitmaps (DIBs) and Device-Dependent Bitmaps (DDBs).

A Device-Independent Bitmap (DIB) stores image data in a standardised format that is independent of the display device. Because the bitmap contains information describing its colour format and pixel layout, it can be transferred between different devices and applications without requiring conversion. DIBs are commonly used for storing bitmap images in files (such as .BMP files), copying images via the clipboard, and exchanging graphics between applications.

A Device-Dependent Bitmap (DDB) is created in a format that is optimised for a particular output device, such as a graphics display or printer. Since the bitmap is stored using the characteristics of the target device, it cannot be transferred directly between different devices without first being converted. DDBs are generally used to improve drawing performance because they are stored in a format that is efficient for the graphics device interface (GDI) to render.

For example, a bitmap stored in video memory for rapid screen drawing is typically a device-dependent bitmap, whereas a bitmap loaded from a .BMP image file is usually represented as a device-independent bitmap before being converted for display.

In practice, Windows applications often load an image as a Device-Independent Bitmap, then convert it to a Device-Dependent Bitmap when it is displayed on the screen. This approach combines the portability of DIBs with the rendering efficiency of DDBs.

Creating and Loading Device-Independent Bitmaps

Device-independent bitmaps are typically created using an image editor. To load a bitmap for use in an application use the LoadImage() function. This supersedes the LoadBitmap() function. The prototype for this function is

HANDLE LoadImage(HINSTANCE hInst, LPCSTR name, UINT type, int cx, int cy, UINT fuLoad);

Where
hInst – is a handle to the module of either a DLL or executable (.exe) that contains the image to be loaded.
name – the image to be loaded.
UINT – The type of image to be loaded.
cx – The width, in pixels, of the icon or cursor.
cy– The height, in pixels, of the icon or cursor.
fuLoad – can be one of the following values: LR_CREATEDIBSECTION; LR_DEFAULTCOLOR;LR_DEFAULTSIZE; LR_LOADFROMFILE; LR_LOADMAP3DCOLORS; LR_LOADTRANSPARENT; LR_MONOCHROME; LR_SHARED; LR_VGACOLOR

If the function succeeds, the return value is the handle of the newly loaded image. If the function fails, the return value is NULL.

For further reading
https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-loadimagea

To convert a DIB to a DDB, use the API function CreateDIBitmap. 
https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-createdibitmap

Displaying Bitmaps

To display a bitmap using the Windows Graphics Device Interface (GDI), two device contexts (DCs) are typically used. The first is the window device context, which represents the drawing surface of the application window. The second is a memory device context, which is an off-screen drawing surface used to temporarily hold the bitmap before it is copied to the window.

The memory device context is created by calling the CreateCompatibleDC() function. This function creates a device context that is compatible with an existing device context, allowing graphics to be prepared in memory before being displayed on the screen. Drawing to a memory device context rather than directly to the window helps reduce flickering and improves drawing performance.

Once the memory device context has been created, the bitmap is selected into it using the SelectObject() function. This associates the bitmap with the memory device context, making it the current drawing surface for that DC.

Finally, the bitmap is copied from the memory device context to the window device context using the BitBlt() (Bit Block Transfer) function. BitBlt() efficiently transfers a rectangular block of pixels from one device context to another, displaying the bitmap in the application window.

The typical sequence of operations is:

1. Obtain the window’s device context using BeginPaint() or GetDC().
2. Create a compatible memory device context using CreateCompatibleDC().
3. Load or create a bitmap.
4. Select the bitmap into the memory device context using SelectObject().
5. Copy the bitmap to the window using BitBlt().
6. Restore the original object in the memory device context.
7. Delete the memory device context using DeleteDC().
8. Release the window device context using EndPaint() or ReleaseDC().

DC=GetDC(hwnd);
memDC=CreateCompatibleDC(DC);
SelectObject(memDC,bitmap1);
BitBlt(DC,x.y,cx,cy, memdc,x1,y1,SRCCOPY);

The syntax for the CreateCompatibleDC function is

HDC CreateCompatibleDC(HDC hdc);

Where hdc is a handle to an existing DC. If this handle is NULL, the function creates a memory DC compatible with the application’s current screen. If the function succeeds, the return value is the handle to a memory DC. If the function fails, the return value is NULL.

The syntax for this Bitblt() copy function is

BOOL BitBlt(HDC hdc,int x,int y,int cx, int cy,HDC hdcSrc,int x1,int y1,DWORD rop);

where
hdc – handle to the destination device context.
x – The x-coordinate upper-left corner of the destination rectangle.
y – The y-coordinate of the upper-left corner of the destination rectangle.
cx – The width of the source and destination rectangles.
cy – The height, in logical units, of the source and the destination rectangles.
HdcSrc – A handle to the source device context.
x1 – The x-coordinate of the upper-left corner of the source rectangle.
y1 – The y-coordinate of the upper-left corner of the source rectangle.
rop – A raster-operation code. Define how the colour data for the source rectangle will be combined with the destination rectangle. The ‘vanilla’ operating code SRCCOPY will copy the source rectangle directly onto the destination rectangle. For additional raster code information see the link below

Bltbmp returns zero if successful and non-zero otherwise.

When a bitmap is no longer needed it must be destroyed using the DeleteObject() API function.

For further information 
https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-bitblt

Repainting the Screen Using Device Dependent Bitmaps

One technique for preserving the contents of a window during repaint operations is to use a device-dependent bitmap (DDB) as an off-screen drawing surface. Instead of drawing graphics directly to the window, all drawing operations are performed on a bitmap stored in memory. This bitmap acts as a back buffer or virtual drawing surface that maintains a copy of the window’s contents.

The bitmap is associated with a memory device context, created using the CreateCompatibleDC() function. All graphics are drawn to this memory device context, ensuring that the bitmap always contains an up-to-date representation of the client area.

Whenever Windows generates a repaint request, such as after the window has been resized, uncovered, or restored, the application does not need to redraw every graphical object individually. Instead, it simply copies the contents of the memory bitmap to the window’s device context using the BitBlt() function. This process is considerably faster than recreating the entire display and helps eliminate screen flicker.

The sequence of operations is as follows:

1. Create a memory device context using CreateCompatibleDC().
2. Create a compatible bitmap using CreateCompatibleBitmap().
3. Select the bitmap into the memory device context using SelectObject().
4. Perform all drawing operations on the memory device context.
5. When a WM_PAINT message is received, copy the bitmap from the memory device context to the window device context using BitBlt().
6. Delete the bitmap and memory device context when they are no longer required.

This technique is commonly referred to as double buffering. By drawing graphics off-screen and then copying the completed image to the display in a single operation, applications can produce smoother graphics, reduce flickering, and improve repaint performance. Although modern graphics frameworks often provide built-in double buffering, this remains an important technique in traditional Win32 GDI programming.

Creating Device-Dependent Bitmaps

The API function CreateCompatibleBitmap() creates a bitmap compatible with the current device context handle. This function is best used for creating colour bitmaps. The prototype of this API function is 

HBITMAP CreateCompatibleBitmap (hdc, cx, cy) ;

Where 
hdc is a handle to a device context
cx is the bitmap width, in pixels
cy is the bitmap height, in pixels. 

If the function succeeds, the return value is a handle to the compatible bitmap (DDB). If the function fails, the return value is NULL.

In addition, a Windows application can also create a device-dependent bit using the CreateBitmap API function. This function is best used for creating monochrome bitmaps. The syntax for this function is

HBITMAP CreateBitmap(int nWidth,int nHeight,UINT nPlanes,UINT nBitCount,const VOID *lpBits);

where
nWidth – The bitmap width, in pixels.
nHeight – The bitmap height, in pixels.
nPlanes – The number of colour planes used by the device.
nBitCount – The number of bits required to identify the colour of a single pixel.
lpBits – Set the colours in a rectangle of pixels. 

If the function succeeds, the return value is a handle to a bitmap. If the function fails, the return value is NULL.

Example

In the code section below, Windows creates a device context of the application window and a compatible device context. The application then creates and fills this virtual copy with 200 random lines. Each time a repaint request is received, the contents of the virtual window are copied to the screen device context by the BitBlt function.

Copying a Bitmap Using the StretchBlt Function

The StretchBlt() function copies a bitmap from a source device context to a destination device context while automatically scaling the image to fit the specified destination rectangle. Depending on the size of the destination rectangle, the bitmap can either be enlarged (stretched) or reduced (compressed).

Unlike the BitBlt() function, which performs a direct pixel-for-pixel copy, StretchBlt() resizes the bitmap during the transfer. This makes it useful for displaying images at different sizes or fitting graphics within a resizable application window.

In the example below, the application captures the current contents of the Windows desktop by creating a bitmap that is compatible with the screen’s device context. The desktop image is copied into a memory device context and then displayed within the application’s client area using the StretchBlt() function. The captured image is automatically scaled to fit the dimensions of the application window.

The screen capture is initiated when the user clicks the left mouse button anywhere within the client area of the application window. After the image has been captured, the application repaints the window using the scaled bitmap whenever a repaint request is received.

The basic sequence of operations is as follows:

1. Obtain the screen device context using GetDC(NULL).
2. Create a compatible memory device context using CreateCompatibleDC().
3. Create a compatible bitmap using CreateCompatibleBitmap().
4. Copy the desktop image into the memory device context using BitBlt().
5. Respond to the WM_PAINT message by calling StretchBlt() to copy and scale the bitmap into the application’s client area.
6. Release all GDI resources, including the bitmap and memory device context, when they are no longer required.

Note: StretchBlt() performs image scaling using the current stretch mode set by SetStretchBltMode(). Higher-quality scaling modes, such as HALFTONE, are available on modern versions of Windows, although older development environments such as Visual C++ 6.0 typically use the default COLORONCOLOR mode.

Example

In the example below, the application captures the current contents of the Windows desktop by creating a bitmap of the screen. When the user clicks the left mouse button anywhere within the application’s client area, the screen image is copied into a memory bitmap. The bitmap is then displayed in the application window using the StretchBlt() API function, which automatically scales the captured image to fit the dimensions of the client window.