Display Buffer Formats
The GDI supports displays with a wide variety of color depths and color models, ranging from 1-bit color to palletized color to true 32-bit RGB color. Each format also supports several pixel orderings, depending on whether access to the display memory is by byte, WORD, or DWORD.
For all display buffer formats, the order of pixels on the display is from left to right and from top to bottom. For example, pixel (0, 0) appears at the upper-left corner of the display, and pixel (width – 1*, height* – 1) appears at the lower-right corner.
1 bit per pixel
The 1-bpp format is for simple black-and-white displays. Black is represented by 0 (zero), and white is represented by 1. Pixel (0, 0) is packed into the highest-order bit of the first byte of display memory.
The following table shows the byte arrangement of memory for the format.
| Byte | Bits | Pixels |
|---|---|---|
| 0 | 7 through 0 | (0, 0) through (0, 7) |
| 1 | 7 through 0 | (0, 8) through (0, F) |
| 2 | 7 through 0 | (1, 0) through (1, 7) |
| 3 | 7 through 0 | (1, 8) through (1, F) |
The following table shows the WORD arrangement of memory for the format.
| WORD | Bits | Pixels |
|---|---|---|
| 0 | F through 8 | (0, 8) through (0, F) |
| 0 | 7 through 0 | (0, 0) through (0, 7) |
| 1 | F through 8 | (1, 8) through (1, F) |
| 1 | 7 through 0 | (1, 0) through (1, 7) |
The following table shows the DWORD arrangement of memory for the format.
| DWORD | Bits | Pixels |
|---|---|---|
| 0 | 1F through 18 | (1, 8) through (1, F) |
| 0 | 17 through 10 | (1, 0) through (1, 7) |
| 0 | F through 8 | (0, 8) through (0, F) |
| 0 | 7 through 0 | (0, 0) through (0, 7) |
2 bits per pixel
The 2-bpp format is typically used for 4-level grayscale displays, although any 4-entry palette works. The following table shows the bits for the associated gray levels.
| Bit 1 | Bit 0 | Gray level |
|---|---|---|
| 0 | 0 | Black |
| 0 | 1 | Dark gray |
| 1 | 0 | Light gray |
| 1 | 1 | White |
The following table shows the byte arrangement of memory for the format.
| Byte | Bits | Pixels |
|---|---|---|
| 0 | 7 through 0 | (0, 0) through (0, 3) |
| 1 | 7 through 0 | (0, 4) through (0, 7) |
| 2 | 7 through 0 | (0, 8) through (0, B) |
| 3 | 7 through 0 | (0, C) through (0, F) |
The following table shows the WORD arrangement of memory for the format.
| WORD | Bits | Pixels |
|---|---|---|
| 0 | F through 8 | (0, 4) through (0, 7) |
| 0 | 7 through 0 | (0, 0) through (0, 3) |
| 1 | F through 8 | (0, C) through (0, F) |
| 1 | 7 through 0 | (0, 8) through (0, B) |
The following table shows the DWORD arrangement of memory for the format.
| DWORD | Bits | Pixels |
|---|---|---|
| 0 | 1F through 18 | (0, C) through (0, F) |
| 0 | 17 through 10 | (0, 8) through (0, B) |
| 0 | F through 8 | (0, 4) through (0, 7) |
| 0 | 7 through 0 | (0, 0) through (0, 3) |
4 bits per pixel
The 4-bpp format is usually a palletized format. The frame buffer itself can be implemented either as 2 pixels packed in to each byte or as 1 pixel per byte.
The following table shows the byte arrangement of memory for the format.
| Byte | Bits | Pixels |
|---|---|---|
| 0 | 7 through 0 | (0, 0) through (0, 1) |
| 1 | 7 through 0 | (0, 2) through (0, 3) |
| 2 | 7 through 0 | (0, 4) through (0, 5) |
| 3 | 7 through 0 | (0, 6) through (0, 7) |
The following table shows the WORD arrangement of memory for the format.
| WORD | Bits | Pixels |
|---|---|---|
| 0 | F through 8 | (0, 2) through (0, 3) |
| 0 | 7 through 0 | (0, 0) through (0, 1) |
| 1 | F through 8 | (0, 6) through (0, 7) |
| 1 | 7 through 0 | (0, 4) through (0, 5) |
The following table shows the DWORD arrangement of memory for the format.
| DWORD | Bits | Pixels |
|---|---|---|
| 0 | 1F through 18 | (0, 6) through (0, 7) |
| 0 | 17 through 10 | (0, 4) through (0, 5) |
| 0 | F through 8 | (0, 2) through (0, 3) |
| 0 | 7 through 0 | (0, 0) through (0, 1) |
If you choose to implement just 1 pixel per byte, the driver should represent the display mode as 8 bpp with a 16-color palette. The relevant bits in each byte should be the 4 lowest bits; the 4 highest bits should always be 0. The following table shows the standard Windows CE–based 16-color palette, which you should use to obtain the best results.
| Color | Red | Green | Blue |
|---|---|---|---|
| White | 255 | 255 | 255 |
| Teal | 0 | 255 | 255 |
| Purple | 255 | 0 | 255 |
| Blue | 0 | 0 | 255 |
| Light gray | 192 | 192 | 192 |
| Dark gray | 128 | 128 | 128 |
| Dark teal | 0 | 128 | 128 |
| Dark purple | 128 | 0 | 128 |
| Dark blue | 0 | 0 | 128 |
| Yellow | 255 | 255 | 0 |
| Green | 0 | 255 | 0 |
| Dark yellow | 128 | 128 | 0 |
| Dark green | 0 | 128 | 0 |
| Red | 255 | 0 | 0 |
| Dark red | 128 | 0 | 0 |
| Black | 0 | 0 | 0 |
5 or 6 bits per pixel
The 5-bpp or 6-bpp format should always use a whole byte for each pixel. The relevant bits must be the low-order bits in the pixel, with unused high-order bits containing 0s.
Displays that use 5 bpp or 6 bpp can choose either to palletize the colors or to use the bits in the pixel to represent the colors directly. For example, you can make 6 bpp a 64-entry palletized display, or you can use the 6 bits in each pixel to represent 4 levels each of red, green, and blue directly.
The following table shows the byte arrangement of memory for the format.
| Byte | Bits | Pixels |
|---|---|---|
| 0 | 7 through 0 | (0, 0) |
| 1 | 7 through 0 | (0, 1) |
| 2 | 7 through 0 | (0, 2) |
| 3 | 7 through 0 | (0, 3) |
The following table shows the WORD arrangement of memory for the format.
| WORD | Bits | Pixels |
|---|---|---|
| 0 | F through 8 | (0, 1) |
| 0 | 7 through 0 | (0, 0) |
| 1 | F through 8 | (0, 3) |
| 1 | 7 through 0 | (0, 2) |
The following table shows the DWORD arrangement of memory for the format.
| DWORD | Bits | Pixels |
|---|---|---|
| 0 | 1F through 18 | (0, 3) |
| 0 | 17 through 10 | (0, 2) |
| 0 | F through 8 | (0, 1) |
| 0 | 7 through 0 | (0, 0) |
8 bits per pixel
The 8-bpp format ideally should use a software-changeable palette that maps 8-bit values onto 24-bit colors. For better performance, compatibility, and image quality, use a palette that contains the default Windows CE–based palette, although this is not required.
The following table shows the byte arrangement of memory for the format.
| Byte | Bits | Pixels |
|---|---|---|
| 0 | 7 through 0 | (0, 0) |
| 1 | 7 through 0 | (0, 1) |
| 2 | 7 through 0 | (0, 2) |
| 3 | 7 through 0 | (0, 3) |
The following table shows the WORD arrangement of memory for the format.
| WORD | Bits | Pixels |
|---|---|---|
| 0 | F through 8 | (0, 1) |
| 0 | 7 through 0 | (0, 0) |
| 1 | F through 8 | (0, 3) |
| 1 | 7 through 0 | (0, 2) |
The following table shows the DWORD arrangement of memory for the format.
| DWORD | Bits | Pixels |
|---|---|---|
| 0 | 1F through 18 | (0, 3) |
| 0 | 17 through 10 | (0, 2) |
| 0 | F through 8 | (0, 1) |
| 0 | 7 through 0 | (0, 0) |
15 or 16 bits per pixel
The 15-bpp or 16-bpp format is a masked, non-palletized format. For either 15 bpp or 16 bpp, 1 pixel is stored in each 2-byte WORD. The 15-bpp format wastes the high-order bit of each word. The following table shows the masks that Microsoft recommends for extracting the red, green, and blue values.
| Color | 15-bit mask | 16-bit mask |
|---|---|---|
| Red | 0x7C00 | 0xF800 |
| Green | 0x3E00 | 0x07E0 |
| Blue | 0x001F | 0x001F |
As the masks show for 15 bpp, the low-order 15 bits of each word contain the pixel data. The unused bit should contain 0.
The following table shows the WORD arrangement of memory for the format.
| WORD | Bits | Pixels |
|---|---|---|
| 0 | F through 8 | (0, 0) |
| 0 | 7 through 0 | (0, 0) |
| 1 | F through 8 | (0, 1) |
| 1 | 7 through 0 | (0, 1) |
The following table shows the DWORD arrangement of memory for the format.
| DWORD | Bits | Pixels |
|---|---|---|
| 0 | 1F through 18 | (0, 1) |
| 0 | 17 through 10 | (0, 1) |
| 0 | F through 8 | (0, 0) |
| 0 | 7 through 0 | (0, 0) |
24 bits per pixel
The 24-bpp format is a true-color format, in which each pixel stores 8 bits for red, green, and blue. The advantage of this format is that image quality is very good. Because each pixel occupies exactly 3 bytes, the pixels can be packed together without wasting memory. The drawback to this format is that because half the pixels in this scheme cross DWORD boundaries, there is a performance penalty in accessing and decoding pixels.
The following table shows the byte arrangement of memory for the format.
| Byte | Bits | Pixels | Channel |
|---|---|---|---|
| 0 | 7 through 0 | (0, 0) | Blue |
| 1 | 7 through 0 | (0, 0) | Green |
| 2 | 7 through 0 | (0, 0) | Red |
| 3 | 7 through 0 | (0, 1) | Blue |
32 bits per pixel
Like the 24-bpp format, the 32-bpp format is a true-color format. Unlike the 24-bpp format, however, the 32-bpp format does not cause pixels to cross DWORD boundaries, although this format is less efficient in memory use. There are two ways to arrange the color channels in this format. One method puts blue in the least significant byte of each pixel, and the other method puts red in the least significant byte. These options correspond to the PAL_BGR and PAL_RGB modes. Use PAL_RGB for slightly better performance. The following table shows the masks that you can use to extract red, green, blue, and alpha channels from each pixel.
| Color | PAL_RGB mask | PAL_BGR mask |
|---|---|---|
| Red | 0x000000FF | 0x00FF0000 |
| Green | 0x0000FF00 | 0x0000FF00 |
| Blue | 0x00FF0000 | 0x000000FF |
If your product does not use an alpha channel, use 0x00000000 as the mask for alpha. Otherwise, the alpha channel may occupy the most significant byte.
The following table shows the DWORD PAL_RGB arrangement of memory for the format.
| DWORD | Bits | Pixels | Channel |
|---|---|---|---|
| 0 | 1F through 18 | Unused | Unused |
| 0 | 17 through 10 | (0, 0) | Blue |
| 0 | F through 8 | (0, 0) | Green |
| 0 | 7 through 0 | (0, 0) | Red |
The following table shows the DWORD PAL_BGR arrangement of memory for the format.
| DWORD | Bits | Pixels | Channel |
|---|---|---|---|
| 0 | 1F through 18 | (0, 0) | Alpha |
| 0 | 17 through 10 | (0, 0) | Red |
| 0 | F through 8 | (0, 0) | Green |
| 0 | 7 through 0 | (0, 0) | Blue |
See Also
Display Drivers | Display Driver Extensions | Display Driver Samples
Last updated on Tuesday, May 18, 2004
© 1992-2003 Microsoft Corporation. All rights reserved.