DDDR/2 - PM Palette Management Support

Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation =PM Palette Management Support= This chapter is a brief guide to Presentation Manager Palette Management. Palette support is an optional functionality that can be provided by a presentation device driver.

Introduction
If the driver does not, or cannot provide this functionality, it is simulated in the graphics engine. An application writer accesses palette function via Graphics Programming Interface (GPI) APIs.

The following topics are described:
 * Palette Management Overview
 * Color Support in OS/2 Version 1.3 - Logical Color Tables
 * Palette Management Functionality
 * Palette Management Conflicts
 * XGA Support for Palette Management
 * -Terminology
 * -Default Palettes
 * -Realizing Palettes
 * -Seamless Modifications
 * -Dithering and BITBLTing


 * Miscellaneous Palette Management Information

Overview
Palette Management is special code, enabling applications to specify exact RGB (color) values for a drawing or image on a particular device. The application's color requests are mapped as closely as possible to the actual colors available in the device's hardware color palette. When possible, the hardware palette is modified to provide the requested RGB values exactly.

Code supporting Palette Management is responsible for arbitrating the conflicting color requests that may occur between different applications running simultaneously. These conflicts arise when more colors are requested than can actually be physically displayed at one time, on the device.

For example, if applications request a total of 350 different RGB values, but the device supports only a 256-color hardware palette, then only a subset of the applications' color requests can be satisfied exactly. The Palette Management code must handle setting the hardware palette to satisfy the color requests, and mapping the remainder of the requests to the closest available color in the hardware palette. The application is relieved of the responsibility of managing its environment at the same time as ensuring that its color requests are satisfied to the best of the ability of the hardware.

Color Support in OS/2 Version 1.3 - Logical Color Tables
With OS/2 1.3, application colors can be specified by means of Logical Color Tables (LCTs), and their more powerful (but very dangerous) variant, the realizable Logical Color Table.

The use of Logical Color Tables to specify colors is limited. Although an application can request RGB color values, these requests are simply mapped to the default colors defined in the device's hardware palette. The color mapping is a nearest color search. The colors in the device's hardware palette are not modified. Consequently, the accuracy of colors obtained using Logical Color Tables is limited on devices which do not have a large number of default colors.

For example, an eight-bit-per-pel device has a maximum of 256 colors available. Such a device may have 20 to 30 red or orange shades defined in its default hardware palette. For most applications, this is an acceptable number. However, to display a sunset in varying shades of red and orange might require 150 different shades in the palette. This would not be possible with Logical Color Tables.

To address this problem in OS/2 1.3, the application used a realizable Logical Color Table. In this case, the application makes a GpiRealizeLCT call, which forces the colors from the realizable Logical Color Table into the device's hardware palette, overwriting the default colors. This has the effect that the image created using the realizable Logical Color Table obtains the exact colors requested. However, the remainder of the desktop is repainted using a color mapping from the original default palette to the new colors in the device palette.

Unfortunately, some desktop objects (such as buttons, icons and bit maps created by other applications) do not repaint correctly. This is because these objects are "BLTed" to the screen, with no color conversion. Given this, it is strongly recommended that an application only make the GPIRealizeLCT call when maximized, and then always restore the default palette before exiting.

Further limitations of realizable Logical Color Tables are that only one can be realized correctly at a time, and there is no method of arbitration. If a second application realizes a different Logical Color Table than a first application, the first application will draw with the wrong colors.

Lastly, it should be noted that the concept of Logical Color Tables has no corollary in Windows 3.0 or 3.1. Windows uses a Palette Management scheme as discussed in the preceding Overview.

Creating and Selecting Palettes
A palette is created by passing an array of RGBs to the GpiCreatePalette function in a similar manner to creating a Logical Color Table. This call returns a handle to the palette created. This handle must be used to address the palette in all other related calls.

Unlike LCTs, palettes are global objects and are not confined to a particular presentation space. An application can create multiple palettes and use a different one for each of its tasks. Palette handles can even be passed between different applications to enable them to share the color palettes.

To start drawing with a particular palette in a Presentation Space (PS), the palette must be selected into the PS using the GpiSelectPalette function. This function associates the PS with the palette, and all subsequent color information is taken from the RGB values in the palette. The colors are addressed by an application in the same way as the colors within an LCT-by specifying indexes into the array of RGBs originally used to create the palette.

Realizing Palettes
If the Presentation Space being used is associated with a Direct Device Context (DC) such as the screen, then the application must call WinRealizePalette, passing the palette handle obtained in the GpiCreatePalette call, before drawing using the palette. It is the WinRealizePalettefunction call that filters to the presentation driver to update the colors in the device's hardware palette. At this time, any palette/color conflicts that occur should be resolved.

Whenever the colors in the device's hardware palette are changed, a WM_ REALIZEPALETTE message is sent to every application. When an application that is using Palette Management APIs receives the WM_REALIZEPALETTE message, it should in turn call WinRealizePalette. The application uses WinRealizePaletteto re-realize every currently active (ie, realized) palette. In this way, WinRealizePalette acquires information about the color requirements of the whole system and can resolve any conflicts.

WinRealizePalette processing may cause a remapping of the colors that an application is using for an existing palette. This occurs as a result of another application realizing a new palette or as a result of a conflict. In this case, an indication will be returned to the application in one of the WinRealizePalette function parameters (pcclr). If pcclr is greater than 0, the application should invalidate its window and redraw its image to use the correct colors/color mapping.

For Presentation Spaces associated with Memory DCs such as bit maps, there is never a need to call WinRealizePalette. Memory DCs are not shared. Therefore, there can never be any palette conflicts. The application always gets the exact colors it requests (up to the limits of the bit map format).

Animating Palettes
If an application wishes to change the colors within its palette often and quickly, then it can use calls to GpiAnimatePalette. This function causes the colors within the application's array of RGBs and the device's hardware palette to change almost simultaneously. The call is filtered to the presentation driver in order to update the device's hardware palette. Changing both the application's colors and the device's palette simultaneously ensures that no repainting is required by the application. The image on the screen is updated by virtue of updating the underlying hardware palette.

To ensure that this process does not produce conflicts, a special flag is used when creating the palette. A palette entry can be marked PC_RESERVED, which indicates that the entry may be animated in the future. This prevents the PC_RESERVED palette entry from being shared with other applications. Therefore, the presentation driver can safely change the hardware entry without side effects in other applications.

BITBLT Conversions
As mentioned earlier, one of the problems with realizable LCTs is that there is no color conversion carried out during a BLT. Under Palette Manager, color conversions are automatically performed when "BLTing" between different color palette definitions in the source and destination. In this way, color consistency is maintained when transferring images between any LCT or palette combination by using a nearest color mapping.

Other Palette Operations
Other operations associated with Palette Manager include resizing palettes, changing the colors within palettes, deselecting palettes, and deleting palettes. Each of these operations is fairly straightforward.

Palette Management Conflicts
There are basically three types of conflict that can occur within a Palette Management system:


 * The first type of conflict, and the easiest to resolve, occurs when different palettes are realized by various applications. In this case, the WinRealizePalette function (ultimately, the presentation driver) must choose which colors the device will display. If the device is capable of displaying all the colors requested, then there is no conflict. Otherwise, it must be decided which of the requested colors will be displayed exactly and which will be mapped to the nearest color. This conflict is easily resolved by giving priority to the palette associated with the application in focus. This ensures that the application with which the user is currently interacting, will get the exact colors it requests (up to the device palette color limit).
 * The second type of conflict involves the relative priority of palette- aware versus Logical Color Table-based applications, when obtaining and using palette entries for drawing. An attempt is always made to grant the exact RGB color requests of a palette-aware application. On the other hand, the color requests of an LCT application are satisfied from the portion of the hardware palette designated as the "default palette". WinRealizePalette processing degrades the number of colors in the default palette to grant the color requests of a palette-aware application. Potentially, the number of default palette entries can be degraded to the set of 20 OS/2 and Windows system colors. This situation is not corrected until the palette- aware application(s) stop processing WM_REALIZEPALETTE messages, as will be discussed in XGA Support for Palette Management - Realizing Palettes, below . Note that even on a focus change to the LCT application, the default palette remains degraded if a palette-aware application is processing WM_ REALIZEPALETTE messages.
 * The third type of conflict derives from the second conflict. The manner in which Logical Color Tables are (and must be) handled affects how Palette Manager's default palette is defined. To understand this conflict, it is important to note that an LCT-based application is not limited to using only the colors in its logical color table. For example, an image composed of many colors may be BLTed to a PS associated with an LCT, perhaps specifying only 16 colors. The image is to be drawn using the nearest colors that are available on the device (defined by the device context associated with the PS). The image is not defined using the colors specified in the Logical Color Table. This is very different from BLTing to a PS associated with a palette. In this case, the colors in the image are mapped to the nearest colors available in the palette. In other words, if an application is using LCTs, there is no way of knowing exactly what colors will be used.
 * Palette Manager must ensure that there is always as wide a range of colors as possible in the default palette. This will in turn ensure that LCTs can be mapped to the nearest color with minimum color degradation. To further complicate the conflict, the entries in the device's hardware palette used to support LCTs (the entries in the default palette) must have physical indexes such that mixing default palette colors produces another default palette color (ie, mixing LCT-mapped colors produces another LCT-mapped color).

XGA Support for Palette Management - Terminology
The following sections address the XGA implementation of Palette Management.

Palette Manager for XGA is only implemented for systems supporting eight bits per pel (256 colors). At four bits per pel (16 colors), there are insufficient colors to make a Palette Management implementation worthwhile. At 16 bits per pel (64K colors), there are sufficient colors available to an application without requiring Palette Management.

To clarify the following discussion, it is necessary to define exactly what is meant by the following terms: Hardware Palette, Physical Index, Logical Palette, Logical Index, and Default Palette.

Hardware Palette: the array of RGBs that the physical device is displaying. It is the exact RGB values that the hardware's digital-to-analog converter uses when displaying each pel on the screen.

Physical Index: a value stored in memory (either video memory (VRAM) or system memory) which represents a single pel. A physical index stored in VRAM is an index into the Hardware Palette. The color information for each pel on the display screen is referenced by a physical index. By using this index into the hardware palette, a driver obtains the exact RGB value for the pel. A physical index stored in a system memory bit map is an index into whatever color information is associated with the bit map. This color information is defined by a Logical or a Default Palette.

Logical Palette: an array of RGB and mapping index pairs created by the device driver when defining a palette (as a result of a GpiCreatePalettecall). For each RGB in the Logical Palette, when the RGB is drawn to a direct DC, the corresponding mapping index is the Physical Index for the color (or nearest color) in the Hardware Palette. These indexes are generated when the Logical Palette is realized and are known collectively as the palette mapping. Note that a logical palette is not the same as a Logical Color Table.

Logical Index: an index into a Logical Palette. It is logical indexes that an application uses to address the colors within a Logical Palette that it has created.

Default Palette: an array of RGBs that specify the colors available for use by LCTs and LCT-based applications.

XGA Support for Palette Management - Default Palettes
The XGA solution for Palette Manager uses five default palettes. Each palette supports a different number of colors and can be distinguished by its size. The default palettes supported are the 256, 128, 64, 32 and 16 entry palettes.

Each default palette is designed to give the best possible range of colors for its size. For example, the 256 entry palette contains the colors used by the 8514/A display adapter in OS/2, Version 1.3. (This has proven to be a good palette for displaying color images and has become the standard for Presentation Manager 256 color bit maps and images defined using 256 color Logical Color Tables.) At the opposite end of the scale, the 16-entry default palette contains the standard VGA colors.

Which default palette is used in a presentation space depends on whether the device context associated with the PS is a Memory DC (a bit map) or a Direct DC (the screen).

Memory DCs
Color handling within a Memory DC is easy. There are never any color request conflicts because DCs are not shared, and bit maps can only be selected into one DC at a time. Therefore, only one application can be drawing into a particular bit map within the memory DC at a time. The color information associated with the bit map is inherited from whatever LCT or Palette is currently associated with the presentation space.

If the PS is using a Logical Color Table, the physical indexes in the bit map are indexes into the 256 entry default palette. This gives as broad a range of colors as possible for the application to use. (Remember that the colors used by an LCT application are not limited to the colors in the logical color table.)

If the PS is using a logical palette, then the physical indexes in the bit map are indexes into this logical palette. This means that the physical indexes are the same as the logical indexes used to draw into the bit map.

One important point to note is that because the color information within the bit map is obtained from the PS, changing the presentation space to be associated with a different logical palette (or switching between an LCT and a logical palette) actually changes the meaning of the indexes in the bit map.

Direct DCs
In a direct DC, the physical indexes stored for an image are indexes into the hardware palette. The hardware palette can be viewed as a combination of a default palette and a number of logical palettes.

At the "start of day" (that is, at power-on, when no Palette Manager applications are running and therefore no logical palettes are in existence ), the hardware palette contains the 256 entry default palette. This makes the best possible range of colors available to LCT applications.

Later, when applications are using logical palettes, any one of the smaller default palettes may be in use, leaving room in the hardware palette for color requests to support multiple logical palettes. For example, the hardware palette may contain the 128-entry default palette and (up to) 128 colors requested from several logical palettes. If the combination of logical palette color requests exceeds 128, the default palette must be reduced further in size to support these requests.

Using this scheme, a maximum of 240 colors in the hardware palette can be allocated to support logical palettes' color requests. The remaining 16 entries in the hardware palette are used for the 16 entry default palette, ensuring that LCT applications will always have available a sensible, minimum number of colors.

Note: The 16-color default palette can also be overwritten if an application creates its logical palette using the flag, LCOL_OVERRIDE_ DEFAULT_COLORS. When this flag is specified, the presentation driver should grant the full hardware palette to an application when it is in the foreground and when its color requests exceed 240.

The driver keeps track of which entries in the hardware palette are allocated to colors from logical palettes, using a set of flags associated with each hardware palette entry. These flags are stored in the fcOptions byte of the RGB2 structure of the hardware palette. (The XGA driver defines new flags in the high order nibble of the fcOptions byte. Doing this does not conflict with the system-defined fcOptions flags in the low order nibble.) Entries in the hardware palette that are allocated to logical palette requests are marked as PC_USED, while entries that are allocated to the default palette are marked PC_DEFAULT.

Each logical palette also keeps track of which entries it has been allocated using the its array of mapping indexes (known as the palette mapping, as discussed above).

The default palette is always divided in half when placed in the hardware palette. The two halves are placed at opposite ends of the palette leaving the central region for logical palette colors. This guarantees that logical mixes of the default colors, mapped to by LCTs, will always result in another LCT-mapped color. In other words, all the colors obtainable when using LCTs are in a closed set. This in an important aspect of the XGA Palette Manager implementation. For example, if this were not the case, a mix may result in an entry in the hardware palette that is allocated to an animating logical palette. This would be very dangerous!

The process of changing the default palette in use with a Direct DC, and allocating entries to logical palettes is described in more detail below under "XGA Support for Palette Management - Realizing Palettes".

XGA Support for Palette Management - Realizing Palettes
Applications realize their palettes using the WinRealizePalette function. This function is passed to the graphics engine and onto the presentation driver through the RealizePalette driver entry point. The driver returns values to WinRealizePalette to indicate what actions are required to keep the system consistent. This makes the RealizePalette function the heart of the Palette Manager system.

Three values are returned from the driver's RealizePalettefunction to WinRealizePalette: The actions taken by WinRealizePaletteprocessing depend on the return values as follows:
 * Number of hardware palette entries changed. (A pointer to a ULONG, pcSlotsChanged, is passed as one of the function parameters).
 * Number of logical palette mapping indexes changed. (This is the function's return value).
 * Flag indicating that the default colors have changed. (A pointer to a set of flags defined as a ULONG, pflType, is passed as one of the function parameters. The flag, RP_DEFAULTSCHANGED, must be set to indicate a change in the default colors.)
 * If the hardware palette is changed, WinRealizePalette will invalidate any saved screen bits. (See the OS/2 Presentation Device Driver Reference for details on saved screen bits).
 * If the hardware palette is changed and the new logical palette is being realized in the foreground, WinRealizePalette will send a WM_REALIZEPALETTE message to every application.
 * If the logical palette mapping indexes are changed, the number of changed indices are passed back to the application to indicate that a repaint is required.
 * If the default colors are changed, WinRealizePalettewill invalidate the entire desktop (forcing everything to be repainted).

When a logical palette is realized in the foreground (ie, the application making the WinRealizePalette call has the focus), then that palette receives priority over any other palettes that were previously realized. To satisfy the color requests of the foreground WinRealizePalette, the driver should overwrite entries in the hardware palette that are allocated to other applications, if necessary.

If the hardware palette is changed, then all the palette mappings for the other logical palettes in the system are invalidated. The return value ( hardware palette entries changed in pcSlotsChanged) will trigger the WinRealizePalette function to send WM_REALIZEPALETTE messages to every other application. Each application will then re-realize its palette (in the background) and repaint if any of its palette color mappings differ from its previously realized mappings. As mentioned above, this is indicated by WinRealizePalette's return value.

When a palette is realized in the background (ie, the application making the WinRealizePalette call does not have the focus), then the driver should not change any entries in the hardware palette that are already mapped by other logical palettes. The presentation driver must either modify hardware palette entries that are currently unused, modify the default palette size to make additional slots available, or locate nearest color matches.

When there are no unused entries in the hardware palette for either foreground or background WinRealizePalette requests, the size of the default palette currently in use is reduced. This makes additional hardware palette entries available to logical palettes. Obviously, the minimum default palette size is 16 entries.

A valid question to ask at this point is: "What do non-palette-aware applications do when they receive a WM_REALIZEPALETTE message?" Whenever a non-palette aware application receives this message, it is not expecting it and does not know how to process it. Traditionally, these types of messages are forwarded to the default window procedure for handling. In the default window procedure, the message processing for WM_REALIZEPALETTE makes a call to realize the default palette. This is not a signal, however, to the driver to actually realize the default 256-color palette. It is a signal that the driver uses to determine when to load the appropriately sized default palette and also to determine when to increase the default palette size. This is discussed in more detail below, but we first must understand how the default palette is established, loaded and decreased in size.

The XGA display driver has a number of default palettes, of varying sizes (as discussed above), and the realization code is responsible for determining which is the appropriate default palette to use.

Actually realizing the default palette (or rather realizing the appropriate one of the default palettes) is extremely simple. The default palette is realized whenever the foreground application requests a "realize default palette" in response to the WM_REALIZEPALETTE message, and either of the following conditions is met:
 * The default palette was not the last palette realized.
 * The size of the default palette has changed.

To realize the default palette, the data is merely copied from the first half of the appropriate default palette structure to the start of the hardware palette, and from the last half of the default palette to the end of the hardware palette. (To ensure that mixing operations form a closed set, the default palette must occupy the extreme ends of the hardware palette). The data in the default palettes is preset, so that both the RGB data and the options field can be placed directly into the hardware palette structure.

A driver enabled for seamless operation also has to consider whether it needs to force additional Windows colors into the default palette, as detailed in XGA Support for Palette Management - Seamless Modifications, below.

It is easy to determine when to move from a larger to a smaller default palette. Simply, if a logical palette is being realized which requires more slots than are currently free in the hardware palette, and the default palette is not at its minimum size, then the presentation driver should move to the next smaller default palette. This process may need to be repeated if the smaller default palette still does not provide sufficient free slots to satisfy the logical palette's requirements.

Movement through the default palettes in the opposite direction (from smaller to larger) is not nearly as straight forward.

It is not enough to simply reinstate the 256-entry default palette as soon as the driver thinks that no logical palettes are in use, since the device driver has a very poor picture of when logical palettes are in effect. (For example, assume that an image is drawn on the screen using a logical palette, but that logical palette is no longer selected into any of the display drivers' presentation spaces, perhaps because a cached-micro PS was used. Then, even though the driver is still showing the image drawn with the logical palette, the driver is unaware that the palette is still active .) Therefore, the movement through progressively larger default palettes must be based on different criteria. It is designed to be closely tied to the driver's receipt of "realize default palette" requests.

Whenever XGA is asked to realize the default palette from a foreground application, it counts the number of unused slots in the hardware palette. If there were enough free slots the last time that the default palette was realized (to allow the next larger default palette to be used), and there are still enough free slots, then the size of the default palette is increased. (It may not always be the case, however, that the number of free slots remains unchanged. Some slots could have been taken by WinRealizePalette requests from non-foreground palette aware applications. This is why there is a delay in increasing the default palette size.) Dependent on the number of free slots, the default palette size can be increased several times-until there are insufficient free slots to move to the next larger default palette, or until the maximum default palette (256 colors) is reached.

In order to prevent prematurely increasing the default palette size, whenever a logical palette is realized in the foreground, the value for "free slots the last time that the default palette was realized" is reset. This ensures that the next "realize default palette" request does not increase the size of the default palette.

If a call to realize the default palette in the foreground causes no increase in the default palette size, the XGA driver reports that there are no mapping changes, but that the hardware palette is changed. This causes the system to send WM_REALIZEPALETTE messages to all applications, and allows the driver to be notified of all logical palettes still in use. However, no repainting is needed since no color mapping changes are reported.

If realizing the default palette causes the default palette size to change, a flag is passed back to WinRealizePalette to force a repaint of the entire desktop.

XGA Support for Palette Management - Seamless Modifications
Supporting seamless windows operation requires some redesign of the Palette Manager code. Briefly, the seamless windows modifications involve making the default Windows system colors available at all times. This is discussed in greater detail in Seamless Windows Support. In overview, seamless support requires the following changes to the Palette Manager design:
 * The default palettes are modified so that the 20 Windows colors are moved to the first and last ten entries in the palettes. This modification does not update the default color entries to exactly match the 20 Windows colors, but moves the closest match to these colors to the top and bottom ten hardware palette entries. Also, the driver's search algorithms for the closest color match are not changed. After a color match has been calculated, a translation table is checked to determine if the location of the color has been modified due to seamless operation.
 * The 32-color default palette is never used, since it does not contain the required 20 Windows colors. Therefore, the sequence of sizes for the default palettes in a seamless implementation are 256, 128, 64, and then 16.
 * Whenever the 16-color default palette (the VGA palette) is in effect, the four additional Windows colors are placed in the hardware palette in locations 8, 9, 246 and 247. The dithering algorithm (discussed below) is unchanged, and still behaves as if there are only 16 colors.
 * Whenever a call to the presentation driver causes a change to be made to the hardware palette, a counter accessible to the seamless windows driver and Windows kernel is incremented. This allows the seamless windows driver and kernel to determine when their internal palette mappings are invalid. Both this counter and the hardware palette structure are part of the PM/WIN -OS/2 shared data area. Using the hardware palette structure, Windows code can determine the exact contents of the palette.
 * The maximum number of colors available for a logical palette's color requests (without the application specifying the flag, LCOL_OVERRIDE_ DEFAULT_COLORS) is now 236.

XGA Support for Palette Management - Dithering and BITBLTing
The implementation of the dithering code in the XGA driver is simplified by the decision that only Logical Color Table-related requests are dithered. This is justified for two reasons:
 * Applications that use logical palettes usually get the exact colors that they request. Therefore, dithering with logical palettes is not required.
 * Dithering with an arbitrary set of colors (as is usually found in a logical palette) is a complex and time-consuming task. The loss in performance due to dithering would not balance the color quality gain.

Dither patterns used to satisfy LCT requests are made up of colors from the current default palette. There is a separate dither scheme for each default palette, specifically tuned to give the best dithering results and performance.

BLT (Block Logical Transfer) color conversions are done on the fly by the XGA's software drawing code. (The software drawing code is essentially a simulation of the XGA drawing hardware, and is used extensively within the XGA driver to avoid the performance costs due to the XGA hardware requiring access to arbitrary system memory). In the case of BLT color conversions, the software drawing code is used because the XGA hardware does not support these conversions. A performance gain is achieved using the simulation code over copying the data into a temporary buffer, converting it, and then BLTing it to its destination.

In all cases, the most accurate BLT conversion is always calculated. However, there are several instances when a conversion is not needed. This is true when converting:
 * From a logical palette memory DC to a logical palette memory DC with the same logical palette.
 * From an LCT memory DC to an LCT memory DC.
 * From an LCT memory DC to an LCT direct DC when the hardware palette contains the 256-entry default palette.
 * From or to a realizable LCT DC.
 * From a bit map which is not associated with a DC.

The destination of the block transfer affects the color conversion scheme as follows:
 * If the destination is an LCT direct DC, the converted colors are limited to those in the default palette currently selected into the hardware palette.
 * If the destination is a logical palette direct DC, then the converted colors are limited to the colors mapped by the logical palette.

For example, an application might be BLTing from a color image in a memory DC to a logical palette direct DC. If the logical palette contains only shades of grey, then it is important that the image is converted to only those greys, even though other colors in the hardware palette may match the colors in the original image exactly.

As a simple optimization, the last conversion table used is cached and is reused if the next requested color conversion is identical. This saves having to recalculate the conversion table for each BLT. Even though only one conversion table is cached, this scheme is quite effective. For example, when the desktop is repainted, all the icons are BLTed to the screen in turn. Each will use the same conversion table resulting in a marked performance improvement. Obviously, the conversion table is invalidated if either the source or destination colors are changed.

Several operations are not supported in the XGA driver as such, but are simulated using the BITBLT primitive. These operations are SaveScreenBitsand RestoreScreenBits. Since the purpose of these operations is to save an area of the screen and restore it later, it is important that no color translation is performed during either the save BITBLT, or during the restore BITBLT. To accomplish this, a new option flag, BBO_NO_COLOR_INFO, is provided which informs the driver that color translation is not required on the BITBLT.

Miscellaneous Palette Management Information

 * When an application defines a logical palette, it is assumed to be defined in priority order. In other words, entry 0 is the most important color, and subsequent entries are of decreasing importance. This means that the display driver should allocate hardware slots in order of the entries in the logical palette, rather than trying to match the most logical entries to physical ones. An extreme example of this is a palette with only two distinct RGB values in it, one in the first entry, and one in each of the other 255 entries, with no entry marked as PC_RESERVED or PC_NOCOLLAPSE.

If there is only one slot in the hardware palette, then this slot will be assigned the color of the logical palette's first entry only matching just one of the 256 entries, whereas the remaining 255 entries could have mapped to that same one slot, providing hardware backing for a much higher proportion of the logical palette. Although obviously contrived, similar situations can occur when the color table of an external bit map is used as a palette, where the color table is not subject to any prioritization of its entries.
 * Although an application realizes a logical palette with entries in a specific order, the presentation driver does not guarantee that these logical palette entries are loaded into the hardware palette in this same order. In fact, as an optimization, the driver searches the current hardware palette for a match to a logical palette's color request and maintains the position/entry in the hardware palette, if a match is found. An application should not assume any particular hardware mapping order based on its logical palette definition.
 * A degradation of the OS/2 desktop and LCT applications may occur when color tables from external bit maps are used as logical palettes. This occurs when an eight-bit-per-pel bit map actually uses far less than 256 colors, but the full 256 colors are used to define its palette. In this case, the Palette Management code will degrade the default palette to 16 entries, when (for example) only 64 distinct colors are used within the bit map. Ideally, a logical palette with only 64 entries should be defined, and the default palette degraded to only 128 (assuming that the default palette previously contained 256 entries).
 * Although not specifically prohibited, it is strongly advised that palette operations are not performed via cached-micro presentation spaces. The problem from the display driver's viewpoint is that a cached-micro Presentation Space provides no continuity for the driver's view of the logical palette. The display driver is only asked to create its device palette when a logical palette is selected into a presentation space, and is then told to destroy its device palette when the logical palette is deselected from the Presentation Space (which for a cached-micro Presentation Space is normally very soon after it is selected). Consequently, if Palette Management functions are issued within cached- micro Presentation Spaces, the driver is continually creating and deleting palettes-even though the application has only created the palette once. In addition, this lack of continuity implies that palette animation within a cached-micro PS is impossible.