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
219
|
<!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 Video Optimization</TITLE>
<META NAME="description" CONTENT="Crystal Space: NeXT Video Optimization">
<META NAME="keywords" CONTENT="Crystal Space: NeXT Video Optimization">
<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="SEC616"></A>
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="cs_251.html#SEC615"> < </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="cs_253.html#SEC617"> > </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.4 Video Optimization </H4>
<!--docid::SEC616::-->
<P>
This section describes video optionization techniques which have been
implemented for the high-level AppKit-based 2D driver, which is the only
Apple/NeXT graphics driver currently available for Crystal Space.
Lower-level CoreGraphics and OpenGL drivers are planned for MacOS/X at some
time in the future.
</P><P>
Unlike programs on some other platforms, OpenStep and NextStep applications do
not have direct access to the display hardware (except via the highly private
"Interceptor" API), thus video performance suffers. MacOS/X Server 1.0
(Rhapsody) saw the introduction of the `<SAMP>NSDirectBitmap</SAMP>',
`<SAMP>NSDirectPalette</SAMP>', and `<SAMP>NSDirectScreen</SAMP>' classes which were presumably
intended to allow lower-level access to the display hardware, however their
interfaces were never fully developed. With the advent of MacOS/X, Apple has
introduced the CoreGraphics and OpenGL APIs which should provide much
better video performance than that which was available in previous incarnations
of the Apple/NeXT platforms.
</P><P>
Under MacOS/X, MacOS/X Server 1.0 (Rhapsody) OpenStep, and NextStep, all
drawing to the display is performed by a separate program called the
<EM>WindowServer</EM>. Whenever an applications needs to draw to the screen, it
actually sends drawing commands across an IPC connection to the
WindowServer, and the WindowServer performs the drawing on the application's
behalf. This negatively impacts video performance in essentially three ways.
</P><P>
<UL>
<LI>
Inter-process communication (IPC) between the application and the
WindowServer is performed serially and tends to be a bottle-neck. Furthermore,
IPC is generally slower than direct memory access.
<P>
<LI>
Image data resides in different address spaces since the application and
WindowServer are separate processes. This means that the image data must
somehow be copied from one address space to the other. Copying large amounts
of data is typically very time-consuming.
<P>
<LI>
Since the application does not own the frame-buffer, it also does not have
access to the frame-buffer's data format. This means that after receiving the
image data, the WindowServer generally has to rearrange it so that it matches
the format of the frame-buffer. This can be a particularly time-consuming
operation since it may require quite a lot of bit-fiddling over quite a lot of
bytes. For instance, the application may supply image data in the format
RRRRGGGGBBBBAAAA, which may be converted to RRRRRGGGGGGBBBBB by the
WindowServer. A further constraint is that the high-level AppKit image classes
only understand a very limited number of pixel formats, so even if the
frame-buffer's precise format is known, there is no guarantee that the AppKit
will support it.
</UL>
<P>
This port of Crystal Space implements video optimizations discussed in the
<CITE>NextStep 3.0 WindowServer Release Notes</CITE> in order to work around these
problems as much as possible. The implemented optimizations are:
</P><P>
<UL>
<LI>
Image data is aligned on a page boundary, allowing it to be sent to the
WindowServer as out-of-band data in a Mach message. This is very fast since
the data need only be mapped into the WindowServer's address space rather than
actually being copied. Page-alignment is guaranteed by using
<CODE>NSAllocateMemoryPages()</CODE> on Cocoa and OpenStep, and and
<CODE>vm_allocate()</CODE> on NextStep.
<P>
<LI>
Image samples are organized in a meshed format.
<P>
<LI>
Data for each pixel includes alpha information.
<P>
<LI>
12-bit RGB data is stored in 16-bits with alpha nybble set to <CODE>0x0f</CODE>.
24-bit RGB data is stored in 32-bits with alpha byte set to <CODE>0xff</CODE>.
<P>
<LI>
The image's "<CODE>rowbytes</CODE> modulo 16" equals the destination buffer's
"<CODE>rowbytes</CODE> modulo 16" and the source data pointer is cacheline-aligned
(16 byte aligned) with the destination data pointer. This is accomplished by
using a Retained-mode window and aligning the left edge of the destination
view on an x-coordinate which is a multiple of 8 for 12-bit color depth, and a
multiple of 4 for 24-bit color depth.
<P>
<LI>
The AppKit view which displays the image uses the identity transform. That is,
it is not flipped, scaled, rotated, etc.
<P>
<LI>
In Cocoa and OpenStep, <CODE>-[NSBitmapImageRep draw]</CODE> is used to draw the
image in the destination view. On NextStep, <CODE>-[NXBitmapImageRep draw]</CODE>
(which is a cover for <CODE>NXDrawBitmap()</CODE>) is used. This ensures that the
image data is passed to to the WindowServer as out-of-band data in a Mach
message via the proprietary `<SAMP>nextimage</SAMP>' PostScript operator.
</UL>
<P>
Many of these optimizations are actually geared toward traditional NeXT
(<CODE>m68k</CODE>) hardware and may not be as effective on other platforms such as
Intel. In some cases using these optimizations on original NeXT hardware,
can result in a very dramatic improvement in video performance. In all cases,
it is presumed that the WindowServer has been optimized to perform well on each
platform when presented with data meeting these prerequisites. Therefore
following these guidelines seems sensible even for non-NeXT hardware.
</P><P>
Some further optimizations are employed which are not discussed in the
WindowServer release notes. These include:
</P><P>
<UL>
<LI>
Disabling PostScript <EM>clipping</EM> in the view in which the image is
displayed. (This item is applicable only to NextStep. In Cocoa and OpenStep,
clipping can not be disabled via the AppKit.)
<P>
<LI>
Allocating a <EM>graphics state</EM> (PostScript's `gstate') for the view. This
saves valuable time whenever focusing on the view, though at the expense of
memory. Without the allocated graphics state cache, the view would otherwise
have to perform certain time-consuming preparation tasks each time before
drawing.
<P>
<LI>
The window which displays the view is `Retained' rather than `Buffered'. This
means that drawing occurs directly on-screen rather than going into a
backing-store which would then have to be flushed to the screen with an
expensive memory copy as an extra step.
</UL>
<P>
It is worth noting that none of the aforementioned video optimizations deal
with 2-bit gray, 8-bit gray, or 8-bit color. Consequently this implementation
does not even attempt to perform any optimization in these cases and simply
hands the WindowServer 12-bit color data and lets the WindowServer massage it
as appropriate. The upshot is that for displays other than 12- and 24-bit
RGB, video performance will probably suffer since the WindowServer will
have to massage and dither color data itself. It is further worth noting,
though, that the majority of OpenStep and NextStep installations on Intel and
NeXT hardware use either 12- or 24-bit RGB frame buffers so the actual
impact of this limitation may not be particularly severe.
</P><P>
<A NAME="NeXT Frame Buffer"></A>
<HR SIZE=1>
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="cs_251.html#SEC615"> < </A>]</TD>
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="cs_253.html#SEC617"> > </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>
|
