[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This section describes the frame buffer format managed by the low-level Cocoa-based 2D driver and the manner in which the pixel data is manipulated. This discussion does not pertain to the OpenGL or CoreGraphics drivers.
With few exceptions, most NextStep, OpenStep, and MacOS/X Server 1.0 (Rhapsody) installations are configured for true-color rather than palletized color. However, true-color is rather relative in the case of the Cocoa-based 2D graphics driver since the `NSBitmapImageRep' class supports only a limited number of configurations for image data. Historically, on NextStep, these configurations were limited to:
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
OpenStep and MacOS/X Server 1.0 (Rhapsody) took a stab at providing more comprehensive color depth support, but in their released state, these facilities provided 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. Historically, the high-level Cocoa API, however, did not have access to this information (without resorting to private and unsupported API), and consequently did not make use of it. Furthermore, even in 8-bit color mode the application had neither access to, nor knowledge of the palette. In this case the 8-bit number is simply an opaque color value of which no further 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.3 Cocoa 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 Cocoa-based 2D driver must itself massage the data into a format suitable to `NSBitmapImageRep' and the WindowServer. This can be a time consuming operation.
Crystal Space's software renderer is unable to produce the proper image format for several reasons.
The upshot is that even though the `NSBitmapImageRep' class supports true-color data and Crystal Space is capable of generating true-color data, the formats are incompatible from the perspective of a Cocoa-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 `NSBitmapImageRep':
One other obstacle to this approach is that on 32-bit RGB big-endian hardware, the `NSBitmapImageRep' 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 Cocoa-based driver has painstakingly eradicated all known bugs of this nature in the software renderer, the framework is still quite fragile and breaks easily.
The Cocoa-based driver employs the second approach since it is more robust and reliable. In the interest of video performance, whenever possible, the 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 becomes somewhat simplified.
The Cocoa-based 2D driver is automatically configured to generate 32-bit
RGB image data when running on machines configured for 24- or 32-bit
RGBA display. Conversion of Crystal Space 32-bit RGB:888 data to
RGBA:8888 needed by `NSBitmapImageRep' and the WindowServer is
encapsulated in the class `CocoaFrameBuffer32'. Just prior to flushing
the image data to the display, `CocoaFrameBuffer32' transmutes the pixel
data into a format suitable for `NSBitmapImageRep'. It also ensures that
the alpha byte is set to 0xff
, as explained in the video optimizations
section, 8.1.1.3 Cocoa 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 (or some other unrecognized configuration). Conversion of Crystal
Space 15-bit RGB:555 data to RGBA:4444 needed by
`NSBitmapImageRep' and the WindowServer is encapsulated in the class
`CocoaFrameBuffer15'. 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.3 Cocoa Video Optimization. To
translate incoming RGB:555 data to RGBA:4444,
`CocoaFrameBuffer15' 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] | [ ? ] |