[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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:
One other obstacle to this approach is that on 32-bit RGB big-endian hardware, the AppKit expects the pixel data to occupy the high-byte of the longword which represents each pixel. Historically, the software renderer has had trouble dealing with pixel data which occupies the high-byte since most programmers working on the renderer only test it with pixel formats which do not occupy that byte. As a consequence, it is common for breakage to occur as changes are made to the renderer. Although the maintainer of the Apple/NeXT ports has painstakingly eradicated all known bugs of this nature in the software renderer, the framework is still quite fragile and breaks easily.
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] | [ ? ] |