Consider just the six major versions of Mac OS X
that have emerged since 2001 (Table 2-3). Whether it??™s market conditions, technical
capabilities, costs, or other factors, the OpenGL implementation on OS X
has to adapt to a changing environment. Further, because the OS depends so
heavily on OpenGL, the implementation has many eyes on its performance. In
short, the OpenGL implementation needs to be adaptable, error free, and high
performance.
To adapt to the changing environment and to mitigate circumstances that give
rise to bugs, the Mac OS OpenGL implementation has been modularized as
a plug-in architecture at multiple levels (Figure 2-3). At the highest level, the
OpenGL interface is managed as a dispatch table of entry points. These entry
points can be changed out according to hints or other environmental factors.
The most common reason for changing these entry points arises when you are
using CGL macros to reduce the overhead of calling into the OpenGL API itself.
(Chapter 6 provides more discussion of CGL macros.)
Beneath the dispatch table, another plug-in layer exists. On OS X, this is referred
to as the OpenGL engine layer. This logical abstraction layer is responsible for
handling all of the device-independent OpenGL state. The OpenGL engine layer
checks the error state, maintains any client state required by the OpenGL speci
?¬?cation, and is responsible for assembling OpenGL commands into a buffer
for submission to the underlying renderer.
Pages:
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