[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
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 `NSDirectBitmap', `NSDirectPalette', and `NSDirectScreen' 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.
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 WindowServer. 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.
This port of Crystal Space implements video optimizations discussed in the NextStep 3.0 WindowServer Release Notes in order to work around these problems as much as possible. The implemented optimizations are:
NSAllocateMemoryPages()
on Cocoa and OpenStep, and and
vm_allocate()
on NextStep.
0x0f
.
24-bit RGB data is stored in 32-bits with alpha byte set to 0xff
.
rowbytes
modulo 16" equals the destination buffer's
"rowbytes
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.
-[NSBitmapImageRep draw]
is used to draw the
image in the destination view. On NextStep, -[NXBitmapImageRep draw]
(which is a cover for NXDrawBitmap()
) 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 `nextimage' PostScript operator.
Many of these optimizations are actually geared toward traditional NeXT
(m68k
) 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.
Some further optimizations are employed which are not discussed in the WindowServer release notes. These include:
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.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |