To appreciate OpenGL it is useful to understand its design philosophy. OpenGL provides a layer of abstraction between graphics hardware and an application program. It is visible to the programmer as a set of routines consisting of about 120 distinct commands. Together these routines make up the OpenGL application programming interface (API). The routines allow graphics primitives (points, lines, polygons, bitmaps, and images) to be rendered to a frame buffer. Using the available primitives and the operations that control their rendering, high-quality color graphics images of 3D objects can be rendered.
The designers of OpenGL present the graphics system as a state machine [7] that controls a well-defined set of drawing operations. The routines that OpenGL supplies provide a means for the programmer to manipulate OpenGL's state machine to generate the desired graphics output. Figure 1 shows a simplified view of OpenGL's abstract state machine. Specifying OpenGL as a state machine allows consistent, precise specification and eliminates ambiguity about what a given operation does and does not do.
The model used for interpretation of OpenGL commands is client-server. This is an abstract model and does not demand OpenGL be implemented as distinct client and server processes. A client-server approach means the boundary between a program and the OpenGL implementation is well-defined to clearly specify how data is passed between the program and OpenGL. This allows OpenGL to operate over a wire protocol much as the X protocol operates but does not mandate such an approach.
The OpenGL specification is window system independent meaning it provides rendering functionality but does not specify how to manipulate windows or receive events from the window system. This allows the OpenGL interface to be implemented for distinct window systems. For example, OpenGL has been implemented for both the X Window System and Windows NT.
The specification which describes how OpenGL intergrates with the X Window System is known as GLX. It is an extension to the core X protocol for communicating OpenGL commands to the X server. It also supports window system specific operations such as creating rendering contexts, binding those contexts to windows, and other window system specific operations.
GLX does not demand OpenGL commands be executed by the X server. The GLX specification explicitly allows OpenGL to render directly to the hardware if supported by the implementation. This is possible when the program is running on the same machine as the graphics hardware. This potentially allows extremely high performance rendering because OpenGL commands do not need to be sent through the X server to get to the graphics hardware.
Graphics systems are often classified as one of two types: procedural or descriptive. Procedural means the programmer is determining what to draw by issuing a specific sequence of commands. Descriptive means the programmer sets up a model of the scene to be rendered and leaves how to draw the scene up to the graphics system. OpenGL is procedural. In a descriptive system, the programmer gives up control of exactly how the scene is to be rendered. Being procedural allows the programmer a high degree of control to achieve the best performance. It is expected that descriptive graphics systems will be implemented using OpenGL as a low level interface. SGI's Inventor toolkit [8] is one example of such a descriptive graphics system.
An overriding goal of OpenGL is to allow the construction of portable and interoperable 3D graphics programs. For this reason, OpenGL's rendering functionality must be implemented in its entirety. This means all the complex 3D rendering functionality described later in the article can be used with any OpenGL implementation. Previous graphics standards often allowed subsetting; too often the result was programs that could not be expected to work on distinct implementations.