[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8.1.1.3 Cocoa Video Optimization

This section describes video optionization techniques which have been implemented for the high-level Cocoa-based 2D driver. This discussion does not pertain to the OpenGL or CoreGraphics drivers.

The OpenGL renderer provides the best video performance when hardware-acceleration is available. When it is not available, the software renderer coupled with the CoreGraphics driver provides the next best solution. As a fallback option there is also a pure Cocoa-based driver which restricts itself to very high-level Cocoa API. Since the Cocoa-based driver does not employ lower-level facilities, such as OpenGL or CoreGraphics, it is slower than those alternatives but it is also more likely to function correctly in unexpected configurations or in the unusual event that the other two drivers can not be used. The pure Cocoa driver is used together with the software renderer, but only when requested explicitly with the command-line option `--canvas=crystalspace.graphics2d.cocoa'. It is never used by default. Alternately, it can be requested via a Cocoa defaults setting. For example, to force all applications to use this canvas, you could invoke the following command from the command-line:

 
defaults write CrystalSpace.Global Video.Software.Canvas \
  crystalspace.graphics2d.cocoa

The Cocoa-based graphics driver had its origins on the NextStep operating system using slow NeXT hardware which was not specially optimized for game-level graphics performance. Most of the optimizations employed in this driver are based upon characteristics of NeXT hardware and are thus probably not terribly relevant to today's hardware.

Unlike programs on some other platforms, NextStep and OpenStep applications did not have direct access to the display hardware (except via the highly private "Interceptor" API), therefore achieving reasonable video performance was a challenge. The YellowBox API featured in MacOS/X Server 1.0 (Rhapsody) saw the introduction of the `NSDirectBitmap', `NSDirectPalette', and `NSDirectScreen' classes which were intended to allow lower-level access to the display hardware, however their interfaces were not fully developed at that time, and were thus mostly unusable. Only with the advent of MacOS/X has access to hardware-level acceleration become possible with the introduction of the public CoreGraphics and OpenGL APIs.

With the high-level Cocoa-based driver 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.

The Cocoa-based 2D driver 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:

The bulk of these these optimizations were geared toward traditional NeXT (m68k) hardware and probably have little or no significance on modern hardware. In some cases using these optimizations on original NeXT hardware, could result in a very dramatic improvement in video performance.

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 NextStep, OpenStep and MacOS/X Server 1.0 (Rhapsody) installations on NeXT and Intel hardware used either 12- or 24-bit RGB frame buffers so the actual impact of this limitation may not have been particularly severe.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

This document was generated using texi2html