BitBlt with PATCOPY is the most common operation, so make it into a special case. Also, the SRCCOPY raster operation is very common and deserves a special case.Ron Gery
Microsoft Developer Network Technology Group
Created: March 20, 1992
Revised July 8, 1992
ABSTRACT
This article discusses the use of devices with high color resolution (more than 8 bit). It provides information useful to both application and device driver writers.
In this article, the term true color refers to the ability of 16-bit and 24-bit devices to display colors with a high level of accuracy. Not included are palette-type devices that are limited in the number of concurrent colors they can display.
True color devices usually use a packed pixel format, where 24-bit devices have 8 bits each of red, green, and blue; and 16-bit devices commonly have 5 bits each of red, green, and blue (some use the extra bit as the sixth bit for one of the colors). The result is stunning color reproduction (especially when compared with a standard VGA) of images with near-photographic quality. The color resolution is usually accompanied by a high screen resolution, commonly starting at 800x600 and increasing to obscene sizes.
The vast amount of color information that these devices maintain results in some limitations. Bitmaps tend to be large and to gobble up system memory. Drawing operations involve transferring large quantities of data, so expect some slowdown (although hardware support for blting, text output, and drawing primitives often minimizes this slowdown).
Because of the device-independent nature of the MicrosoftÒ WindowsÔ graphics device interface (GDI), applications should not need to make any special adjustments to run on a true color device. All color values passed to GDI functions are specified as 24-bit values (8 bits each of red, green, and blue), and these translate even better to true color devices than they do to VGA-resolution devices.
Applications using palettes also work without a change. Palette realization does not change the color table on the hardware, but GDI dereferences any color references based on that palette (PALETTEINDEX colors, device-independent bitmap [DIB] color tables with indexes using DIB_PAL_COLORS) and converts them to standard RGB values for the device. Applications using PALETTERGB values circumvent the Palette Manager because the colors are treated as simple RGB values.
One warning note: Device-dependent bitmaps tend to be large on true color devices. Excessive use of large bitmaps will strain the system’s global memory.
Using GetDeviceCaps reveals some interesting information on a true color device. The most interesting is the NUMCOLORS value and its relatives, NUMPENS and NUMBRUSHES, which are set to very large values. A 24-bit driver has a NUMCOLORS of 0xFFFF, and a 16-bit driver using 15 bits has 0x7FFF; an application should probably avoid attempting to track all available colors. A better solution in theses cases is to assume that all colors are available.
Using EnumObjects to enumerate pens and brushes is also meaningless. A true color driver should not continue to enumerate every possible object ad infinitum. That is overkill. Enumerating only a core set of objects—for example, those that the standard VGA driver enumerates—provides sufficient information for applications expecting a low-resolution device without overloading their ability to handle large enumerations.
Devices with true color should not be marked as palette devices (the RC_PALETTE bit of RASTERCAPS should be set to zero). The accompanying palette values—SIZEPALETTE, NUMRESERVED, and COLORRES—need not be set.
The value of BITSPIXEL * PLANES, which defines the color resolution of the device, could equal 32, which surpasses the expected limit of 24. The number 32 is perfectly valid and is used by device drivers written for hardware based on an architecture of 32 bits per pixel. As far as Microsoft Windows is concerned, the device has only 24 bits of color resolution, and the additional 8 bits of information are not used. Device-dependent bitmap allocation, however, is calculated using 32 bits of information per pixel.
In Windows version 3.0, there are three known problems with the way the system deals with true color devices. All are fixed in Windows version 3.1.
1.GDI’s simulation of StretchBlt calls the driver’s GetDIBits function with a bits buffer that is too small. Attempting to perform the operation correctly causes a UAE. The workaround is to have the driver support StretchBlt on its own. The Microsoft Windows version 3.0 Device Driver Kit has detailed information about the device driver interface (DDI) involved. True color drivers should support StretchBlt (regardless of the status of the problem) because GDI’s simulation using 24-bit DIBs is inherently slow and will be bettered by a device-dependent implementation within the driver.
2.Certain icons appear in monochrome instead of color. This is a bug in the icon extraction code, in which the first icon in the icon list is always chosen for these devices. There is no workaround for this problem, but it is only a visual glitch and is not serious. The icons in Control Panel show this problem.
3.When an icon is dragged (either a minimized application or an icon inside Program Manager), it turns into an uninitialized monochrome block instead of a nice monochrome representation of the original icon. When the icon is dropped, it returns to its normal state. There is no workaround for this problem either.
Several applications shipped with Windows version 3.0 also have some problems with true color devices, most notably Paintbrush (for version 3.0), which hangs when booting by trying to allocate space for 0xFFFF brushes.
Speed is the biggest limitation of true color devices. Because the amount of information needed to display anything on these devices is significantly greater than that for a low-resolution device such as a VGA, optimizing for speed is important. Below are recommendations for getting the most perceived speed from a driver.
BitBlt with PATCOPY is the most common operation, so make it into a special case. Also, the SRCCOPY raster operation is very common and deserves a special case.
Fast text output is critical for getting Windows to “feel” fast, so spend some time tuning the text-handling code. Caching fonts in device memory can also result in improved speed.
If a hardware blter is available, use it as much as possible.
If the hardware can support any of GDI’s primitives, use the hardware instead of GDI’s simulations by marking the appropriate capability bits in the GDIINFO structure.
Support StretchBlt in the driver because the simulations will be slow for big bitmaps.
If the hardware has a lot of memory, look into using device bitmaps (a new feature of Windows version 3.1) that allow storing device-dependent bitmaps in device memory.