1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<!-- Created by texi2html 1.64 -->
<!--
Written by: Lionel Cons <Lionel.Cons@cern.ch> (original author)
Karl Berry <karl@freefriends.org>
Olaf Bachmann <obachman@mathematik.uni-kl.de>
and many others.
Maintained by: Olaf Bachmann <obachman@mathematik.uni-kl.de>
Send bugs and suggestions to <texi2html@mathematik.uni-kl.de>
-->
<HTML>
<HEAD>
<TITLE>Crystal Space: NeXT Frame Buffer</TITLE>
<META NAME="description" CONTENT="Crystal Space: NeXT Frame Buffer">
<META NAME="keywords" CONTENT="Crystal Space: NeXT Frame Buffer">
<META NAME="resource-type" CONTENT="document">
<META NAME="distribution" CONTENT="global">
<META NAME="Generator" CONTENT="texi2html 1.64">
</HEAD>
<BODY LANG="" BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#800080" ALINK="#FF0000">
<A NAME="SEC617"></A>
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="cs_252.html#SEC616"> < </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="cs_254.html#SEC618"> > </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="cs_247.html#SEC611"> << </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="cs_248.html#SEC612"> Up </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="cs_257.html#SEC623"> >> </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="index.html#SEC_Top">Top</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="cs_toc.html#SEC_Contents">Contents</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="cs_285.html#SEC711">Index</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="cs_abt.html#SEC_About"> ? </A>]</TD>
</TR></TABLE>
<HR SIZE=1>
<H4> 8.1.1.5 Frame Buffer </H4>
<!--docid::SEC617::-->
<P>
With few exceptions, most MacOS/X, MacOS/X Server 1.0 (Rhapsody), OpenStep, and
NextStep installations are configured for <EM>true-color</EM> 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:
</P><P>
<BLOCKQUOTE>
<TABLE>
<TR><TD>2-bit gray </TD><TD> <CODE>NX_TwoBitGrayDepth</CODE></TD>
</TR>
<TR><TD>8-bit gray </TD><TD> <CODE>NX_EightBitGrayDepth</CODE></TD>
</TR>
<TR><TD>8-bit color </TD><TD> <CODE>NX_EightBitRGBDepth</CODE> (via RGB palette)</TD>
</TR>
<TR><TD>12-bit color </TD><TD> <CODE>NX_TwelveBitRGBDepth</CODE></TD>
</TR>
<TR><TD>24-bit color </TD><TD> <CODE>NX_TwentyFourBitRGBDepth</CODE></TD>
</TR></TABLE>
</BLOCKQUOTE>
<P>
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.
</P><P>
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.
</P><P>
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, <A HREF="cs_252.html#SEC616">8.1.1.4 Video Optimization</A>.
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.
</P><P>
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.
</P><P>
Crystal Space is unable to produce the proper image format for several reasons.
</P><P>
<UL>
<LI>
The rendering engine has no facilities for forcing certain unused bits to
conform to a certain value. In this case the alpha bits need to be set to one.
<P>
<LI>
The rendering engine does not support the common AppKit display modes. For
instance, the software rendere has modes for only 8-bit, 15-bit, and 16-bit,
but not the 12-bit RGB data which is expected by the AppKit image classes.
<P>
<LI>
For performance reasons of its own, the software renderer is hard-coded to
produce pixel data in the format NBGR for big-endian and NRGB for
little-endian (as seen from a CPU register perspective), where `N'
represents unused and potentially uninitialized bits. Neither of these pixel
formats is suitable for the AppKit image classes.
</UL>
<P>
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.
</P><P>
There are at least a couple of solutions to the problem of pixel-format
mismatch between Crystal Space's software renderer and the AppKit:
</P><P>
<UL>
<LI>
Parameterize the software renderer's currently hard-coded constants such that
those constants can be modified at compile-time, and then build several
versions of the renderer, each geared for a particular pixel format. To some
extent, this approach has already been implemented for a few fixed 8-, 15-,
16-, and 32-bit pixel formats, however extending it to handle the many existing
(and potential future) Apple/NeXT formats could become quickly nightmarish,
as well as leading to bloat.
<P>
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.
</P><P>
<LI>
Allow the renderer to generate pixel data in one of its hard-coded formats and
then massage the data into a format suitable for the AppKit and WindowServer in
a post-processing step just before sending it off to the WindowServer. The
downside to this approach is that post-processing can be time-consuming as well
as memory intensive since such processing involves copying the pixel data from
one frame-buffer to another. (The double frame-buffer requirement is a
limitation of the way in which many Crystal Space applications deal with the
frame-buffer. These applications expect that the frame-buffer data will remain
valid and unmodified from frame to frame, thus massaging the data in-place is
not a workable approach.) The benefit of the post-processing approach, on the
other hand, is that it is much less fragile than parameterizing the renderer.
</UL>
<P>
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.
</P><P>
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
`<SAMP>NeXTFrameBuffer32</SAMP>'. Just prior to flushing the image data to the
display, `<SAMP>NeXTFrameBuffer32</SAMP>' transmutes the pixel data into a format
suitable for the AppKit. It also ensures that the alpha byte is set to
<CODE>0xff</CODE>, as explained in the video optimizations section, <A HREF="cs_252.html#SEC616">8.1.1.4 Video Optimization</A>.
</P><P>
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 `<SAMP>NeXTFrameBuffer15</SAMP>'. 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
<CODE>0x0f</CODE> as explained in the video optimizations section, <A HREF="cs_252.html#SEC616">8.1.1.4 Video Optimization</A>. To translate incoming RGB:555 data to RGBA:4444,
`<SAMP>NeXTFrameBuffer15</SAMP>' 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.
</P><P>
<A NAME="NeXT Dynamic Linking"></A>
<HR SIZE=1>
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="cs_252.html#SEC616"> < </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="cs_254.html#SEC618"> > </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="cs_247.html#SEC611"> << </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="cs_248.html#SEC612"> Up </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="cs_257.html#SEC623"> >> </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="index.html#SEC_Top">Top</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="cs_toc.html#SEC_Contents">Contents</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="cs_285.html#SEC711">Index</A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="cs_abt.html#SEC_About"> ? </A>]</TD>
</TR></TABLE>
<BR>
<FONT SIZE="-1">
This document was generated
using <A HREF="http://www.mathematik.uni-kl.de/~obachman/Texi2html
"><I>texi2html</I></A>
</BODY>
</HTML>
|
