Graphics Reference
In-Depth Information
Figure 2.1.
Some graphics standards that led to OpenGL.
of expectations for the quality of images they could produce. In turn, these led
to the graphics engines developed by companies like Evans and Sutherland
(E&S) and Silicon Graphics (SGI) and others that began to implement basic
graphics processes in hardware. These again increased the expectations of per-
formance and quality. A part of the “family tree” of public, non-proprietary
graphics standards is shown in Figure 2.1.
Originally, graphics standards were meant to solve portability problems.
That is, graphics standards enabled programmers to re-deploy existing appli-
cations on different hardware systems with a minimal amount of work. But as
hardware acceleration became more common, graphics standards also became
a blueprint for what operations needed to be accelerated.
For example, in order to take advantage of the SGI graphics engines,
the engineers at SGI also developed a graphics API that mapped well to the
engines' processes. This was Iris GL, and it made developing graphics applica-
tions so much more straightforward that an industry-wide version was cre-
ated. The resulting OpenGL API can be said to have been one of the key factors
that has made graphics so ubiquitous in the computing world. Of course, oth-
ers have looked at OpenGL and have believed they could do beter by match-
ing the API more closely to their particular platforms or by extending the func-
tionality of the API in different ways, so we continue to find ourselves in a
world with many competing “standards.”
OpenGL makes no assumptions of hardware support. The spec only says
what should be done, not how it should happen, or how fast. It is possible
to implement OpenGL entirely in software without affecting the applications
in any way except speed. However, many—perhaps most—graphics appli-
cations need to create images at interactive speeds. This is particularly true
