Graphics Reference
In-Depth Information
4.2
Programming Graphics APIs
Figure 4.3
illustrates that one way to understand a modern graphics API is by
GHC and RC. These are
names and abbreviations in-
troduced in this topic for the
convenience of discussion. In
general, there is no indus-
try standard or recommenda-
tion for organizing interfaces
to graphics APIs.
considering the API as a functional interface to the underlying graphics hardware.
It is convenient to consider this functional interface as consisting of two stages:
the graphics hardware context (GHC) and the rendering context (RC).
Graphics hardware context (GHC). This stage is depicted as the vertical el-
lipse in Figure 4.3. We think of the GHC as a configuration that wraps over
the hardware video display card. An application creates a GHC for each unique
configuration (e.g., number of representable colors) of the hardware video card(s).
When we issue drawing commands, geometries are rendered into hardware render
buffers inside the GHC. The right side of Figure 4.3 shows that when a graphics
API presents a rendered image, the image is flushed onto the GUI-created drawing
area. For example, referring to Listing 3.3, where in Step 3 we clear the interme-
diate (hardware render) buffers and then in Step 4 the contents of the buffers are
presented to the GUI-created drawing area. It is possible for an application to
draw to multiple drawing areas. Figure 4.3 illustrates that one way would be as-
sociating multiple drawing areas (and buffers) with a single rendering context.
Another way would be creating multiple rendering contexts to support drawings
with different rendering parameters.
GUI API
(A): Initialize
Graphics Hardware
(B): Create
Rendering Context
Present
drawings
(C1): Prepare
for drawing
(C2): Drawing
commands
Rendering State
M
M
M
Rendering Context
Our
Application
Rendering State
Graphics
Hardware
Context
Hardware
render buffers
M
M
M
GUI drawing
areas
Rendering Context
Figure 4.3.
Working with a graphics API.
Search WWH ::




Custom Search