Graphics Reference
In-Depth Information
desktop display of, say, driving directions might show the entire route,
while the cellphone display might show a scrollable and zoomable small
portion. Since display pixel sizes vary widely, physical units make more
sense than pixel counts in many cases.
• Does the graphics platform handle updates via a changing model? If the
platform has you update a model of what is to be displayed and then auto-
matically updates the display whenever necessary, querying that model as
needed, the programming demands are relatively simple but the way in
which updates are handled may be beyond your control. A system that does
not
provide such updating would, for example, require the application to
do “damage repair” when movement of overlapped windows reveals new
areas to be displayed. Programs in which screen display can be very expen-
sive (some image-editing programs are like this) prefer to handle damage
repair themselves so that when a user moves a window in which an image
is displayed, the newly revealed parts are only filled in occasionally dur-
ing the move, since constantly filling in the parts could make the move too
slow for comfortable use.
Many 2D graphics fall into the category in which there is little physical real-
ism, most of the objects displayed have associated behaviors, and the display is
updated relatively infrequently. Much of 2.5D graphics applications, in which one
works with multiple 2D objects that are “stacked one on top of the other” (the lay-
ers in many image-editing programs fit this model), also produce imagery that is
far from realistic. The cost of updating the display may become a critical resource
in some of these programs. By contrast, many 3D graphics applications rely on
simulation and realism, and objects in 3D scenes tend to have less “behavior” in
the sense of “reactions to interactions with devices like the mouse or keyboard,”
although this is rapidly changing.
Not surprisingly, the different requirements of 2D, 2.5D, and 3D programs
means that there is no one best answer to many questions in graphics. The circuit-
design program doesn't need physically realistic rendering capability, just as the
twitch game doesn't typically need much of an interaction-component hierarchy.
The programmer who sets out to write a graphics program has a wide choice of
starting points. Because graphics cards—the hardware that generates data to be
displayed on a screen—or their equivalent chipsets vary widely from one machine
to the next, it's typical to use some kind of software abstraction of the capabilities
of the graphics card. This abstraction is known as an
application programming
interface
or
API.
A graphics API could be as simple as a single function that lets
you set the colors of individual pixels on the display (although in practice this
functionality is usually included as a tiny part of a more general API), or it could
be as complex as a system in which the programmer describes a scene consisting
of high-level objects and their properties, light sources and their properties, and
cameras and their properties via the API, and the objects in the scene are then
rendered as if they were illuminated by the light sources and seen from the par-
ticular cameras. Often such high-level APIs are just a part of a larger system for
application development, such as modern game engines, which may also provide
