Next: 4.4.1 The Matrix Stack Up: 4 Design Features Previous: 4.3.1 Vertices and Associated

4.4 Modal

As a consequence of fine-grained control, OpenGL maintains considerable state, or modes, that determines how primitives are rendered. This state is present in lieu of having to present a large amount of information with each primitive that would describe the settings for all the operations to which the primitive would be subjected. Presenting so much information with each primitive is tedious and would result in excessive data being transmitted from client to server. Therefore, essentially no information is presented with a primitive except what is required to define it. Instead, a considerable proportion of OpenGL commands are devoted to controlling the settings of rendering operations.

One difficulty with a modal API arises in implementations in which separate processors (or processes) operate in parallel on distinct primitives. In such cases, a mode change must be broadcast to all processors so that each receives the new parameters before it processes its next primitive. A mode change is thus processed serially, halting primitive processing until all processors have received the change, and reducing performance accordingly. One way to lessen the impact of mode changes in such a system is to insert a processor that distributes work among the parallel processors. This processor can buffer up a string of mode changes, transmitting the changes all at once only when another primitive finally arrives[1].

Another way to handle state changes relies on defining groups of named state settings which can then be invoked simply by providing the appropriate name (this is the approach taken by X and PEX). With this approach, a single command naming the state setting changes the server's settings. This approach was rejected for OpenGL for several reasons. Keeping track of a number of state vectors (each of which may contain considerable information) may be impractical on a graphics subsystem with limited memory. Named state settings also conflict with the emphasis on fine-grained control; there are cases, as when changing the state of a single mode, when transmitting the change directly is more convenient and efficient than first setting up and then naming the desired state vector. Finally, the named state setting approach may still be used with OpenGL by encapsulating state changing commands in display lists (see below).




Next: 4.4.1 The Matrix Stack Up: 4 Design Features Previous: 4.3.1 Vertices and Associated


segal@asd.sgi.com
Fri Sep 23 17:28:42 PDT 1994