[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8.1.1.5 Frame Buffer

With few exceptions, most MacOS/X, MacOS/X Server 1.0 (Rhapsody), OpenStep, and NextStep installations are configured for true-color rather than palettized color. However, true-color is rather relative in the case of the AppKit-based 2D graphics driver since the AppKit supports only a limited number of configurations for image data. In particular, these are:

2-bit gray NX_TwoBitGrayDepth
8-bit gray NX_EightBitGrayDepth
8-bit color NX_EightBitRGBDepth (via RGB palette)
12-bit color NX_TwelveBitRGBDepth
24-bit color NX_TwentyFourBitRGBDepth

MacOS/X Server 1.0 and OpenStep take a stab at providing more comprehensive color depth support, but in their current state, these facilities provide little additional assistance and, consequently, are not discussed further.

At the lowest level, the WindowServer itself supports additional configurations and adjusts appropriately to the underlying hardware. The high-level AppKit API, however does not have access to this information (without resorting to private and unsupported API), and consequently can not make use of it. Furthermore, even in 8-bit color mode the application has neither access to, nor knowledge of the palette. In this case the 8-bit number is simply an opaque color value from which no furthre interpretation can be made.

To further complicate matters, in order to achieve decent video performance, image data sent to the WindowServer needs to be specially formatted, as discussed in the video optimizations section, 8.1.1.4 Video Optimization. In particular, for optimal performance, 12-bit and 24-bit data must include an alpha channel and all alpha bits must be set to one.

Unfortunately the Crystal Space software renderer is unable to produce image data in a format usable by the WindowServer when video performance is a concern. This is unfortunate since it means that the AppKit-based 2D driver must, itself, massage the data into a format suitable to the AppKit and the WindowServer. This can be a time consuming operation.

Crystal Space is unable to produce the proper image format for several reasons.

The upshot is that even though MacOS/X, MacOS/X Server 1.0 (Rhapsody), OpenStep, and NextStep support true-color data and Crystal Space is capable of generating true-color data, the formats are incompatible from the perspective of an AppKit-based 2D driver.

There are at least a couple of solutions to the problem of pixel-format mismatch between Crystal Space's software renderer and the AppKit:

In the interest of video performance, whenever possible, the AppKit-base 2D driver attempts to perform as much of the time-consuming post-processing work in a one-time initialization step. The additional benefit of performing some of the time-consuming work in an initialization step is that the actual post-processing step is simplified to some extent.

The AppKit-based 2D driver is automatically configured to generate 32-bit RGB image data when running on MacOS/X, MacOS/X Server 1.0 (Rhapsody), OpenStep, and NextStep machines configured for 24- or 32-bit RGBA display. Conversion of Crystal Space 32-bit RGB:888 data to RGBA:8888 needed by the AppKit and WindowServer is encapsulated in the class `NeXTFrameBuffer32'. Just prior to flushing the image data to the display, `NeXTFrameBuffer32' transmutes the pixel data into a format suitable for the AppKit. It also ensures that the alpha byte is set to 0xff, as explained in the video optimizations section, 8.1.1.4 Video Optimization.

The 2D driver is automatically configured to generate 15-bit RGB image data when running on machines configured for 12-, 15-, or 16-bit RGBA display. Conversion of Crsytal Space 15-bit RGB:555 data to RGBA:4444 needed by the AppKit and WindowServer is encapsulated in the class `NeXTFrameBuffer15'. In order to avoid time-consuming bit manipulation of image data, this class generates a translation table which equates each possible RGB:555 color value with the corresponding RGBA:4444 color. The alpha nybble of the translated color contains 0x0f as explained in the video optimizations section, 8.1.1.4 Video Optimization. To translate incoming RGB:555 data to RGBA:4444, `NeXTFrameBuffer15' enumerates over each color value in the incoming image data, looks up its corresponding RGBA:4444 value in the translation table and outputs that color. This technique is both simple and reasonably efficient.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

This document was generated using texi2html