Introduction - Computer Graphics and Geometric Modeling - page 9

Note that replace mode would cause this loop to erase everything in the cursor's
path and leave behind a trail of the cursor. There is one disadvantage with
the xor operation, however, which may not make it a viable option in certain situa-
tions. Although one can use it to move objects around on the screen without destroy-
ing the background, the objects may change color. If, for example, one wants to move
a red cursor and have it stay red, then this is not possible with xor mode because
the cursor will assume different colors as it moves over differently colored areas
of the screen. Therefore, if it is important that the cursor stay red, then there is
no simple alternative to first saving the area to which one is writing and restoring it
afterwards.
Because the availability of logical operators in store operations simplifies
and speeds up many useful graphics operations, current graphics systems have
built-in hardware support for them. We will have more to say about this in Section
2.10.
We finish this section with two more terms one sees frequently in graphics. Scan
conversion is the act of converting points, lines, other geometric figures, functions,
etc., into the raster data structure used in frame buffers one scan line at a time. After
a scene is modeled, it needs to be “rendered.” To render a scene means to construct
an image on a display device that is visually satisfactory. What is “satisfactory”
depends firstly on the device and its constraints and secondly on what one is trying
to do. To emphasize the position that rendering occupies in graphics, keep in mind
that the modeling or mathematical representation comes first and then the rendering.
Any given model can have many different renderings. For example, a sphere can be
rendered in different colors. In trying to render scenes one runs into a number of
important problems: visible line or surface determination, illumination, texturing,
transparency, etc. These will all be addressed in coming chapters.

1.4 Graphics Standards and Primitives

A person who wants to develop a graphics program has to learn how to access the
graphics capabilities of the system that he/she is working on. Unfortunately, there are
many graphics devices out there in the world. If one wanted a program to work with
all those devices and if one had to program the hardware directly, then one could
easily spend all of one's time on very low-level code and never get to that in which
one is really interested. Therefore, let somebody else, say the manufacturer of the
system or the compiler vendor, worry about the low-level stuff so that one can con-
centrate on higher-level ideas. This is where software graphics standards come in.
They are the interface between a high-level language and the low-level code that talks
to the actual hardware. The interface is basically a specification of high-level graph-
ics primitives. As long as one's code calls only these primitives, a program will run on
any system that is supported by that particular interface. In other words, standards
make code portable by making it device independent .
Lots of different standards exist with some more sophisticated than others. The
early DOS operating system standards, such as the Borland Graphics Interface (BGI),
were fairly primitive. Any program in Borland PASCAL or C/C++ that used the Borland
PASCAL or C/C++ graphics primitives was guaranteed to run under DOS on most of