Herd Software Development
DaVinci Graphics Library
DaVinci Documentation

An introduction to DDBs (Device Dependent Bitmaps)

Design

DDBs are so named because their storage format depends on the device where the bitmap will be sent for display (usually either the screen or the printer driver). When you see the term "bitmap" used in reference to Windows API calls, it usually means that the author is referring to a DDB. Functions such as CreateBitmap, LoadBitmap, BitBlt, StretchBlt, and other functions you'd normally associate with bitmap manipulation, work with DDBs.

But while DDBs contain resolution information for the output device, they aren't suitable for saving as disk files. In order to transfer a DIB to a DDB, applications uses the functions CreateDIBitmap and/or BitmapFromDIB. Applications use the function GetDIBits and/or DIBFromBitmap. for the inverted transformation. These functions require the specification of a device context (DC) in order to set up the image data for proper output to the target device. These functions allow the specified device context to be a printer, a screen, or any similar device. Other functions such asLoadBitmap, which does not have a device context as one of its parameters, will implicitly use the DC of the screen. That means that a handle to a bitmap (HBITMAP) returned by LoadBitmap cannot be output to every printer, and may not be suitable for output to printers that can accept it.

Microsoft has specified the monochrome Black/White format as a special case for a DDB, which is to be supported by all graphic device drivers and therefore can be exchanged between all DCs.

DDBs may also be unsuitable for direct manipulation when you want to process an image without modifying its basic format, because the the color depth of the bitmap is converted to the color depth of the target DC when it is converted to a DDB. For example, if you load a DIB into a control on the screen as a DDB and the user has only 16 colors set as their current resolution, then your DDB becomes a 16 color image.

Advantages

The primary advantage of a DDB's unit dependency is that it displays at high speed. It may be possible to process a DDB directly via video driver, as in the following example:

Example: Drawing of a text into a DIB making use of a DDB

HDIB DrawTextInDIB(HDIB hDIB, LPCSTR szText)
{
  HBITMAP    hBitmap,
             hbmo
  HDC        hMemDC;
  HDIB       hNewDIB;

  hBitmap = BitmapFromDIB(hDIB, NULL);
  hMemDC = CreateCompatibleDC(NULL);
  hbmo   = SelectObject(hMemDC, hBitmap);

  TextOut( hMemDC, 10, 10, szText, lstrlen(szText) );

  SelectObject(hMemDC, hbmo);
  DeleteDC(hMemDC);

  hNewDIB = DIBFromBitmap(hBitmap, BI_RGB, 0, NULL);
  DeleteObject(hBitmap);

  return hNewDIB;
}

Disadvantages

Depending on the application, image information may be lost during the conversion from DDB back into DIB.

The transformation of a DIB with low color depth but many pixels (wide and high) can lead to an enormous memory requirement. Example: DIB for a facsimile = approx. 8 million pixels (1 MByte) as DDB for a TrueColor graphic card 1 million times 3 bytes = 24 MByte.

The use of the video driver's palette for display of a DDB may result in a nonstandard palette when the DDB is converted back into a DIB.

History

Prior to Windows 2.0, DDBs were the only from of graphic representation supported by Windows. With the introduction of DIBs as of Windows 3.0 and the accompanying proliferation of video cards with accelerator chips, the use of DDBs has declined significantly. The Win32 API now offers the CreateDIBSection API to allow drawing functions to be performed directly on DIBs. As the API has evolved, the need for DDBs has declined accordingly. But you may find DDBs to be irreplaceable for many 16 bit applications.