Graphics Reference
In-Depth Information
We'll start with the state of the art of raster graphics in the 1980s and early 1990s.
The typical popular 2D raster graphics platform (e.g., Apple's original QuickDraw
and Microsoft's original GDI) provided the ability to paint pixels on a rectangular
canvas, using an integer coordinate system. Instead of painting individual pixels,
the application painted a scene by calling procedures that drew
primitives
that
were either geometric shapes (such as polygons and ellipses) or preloaded rect-
angular images (often called bitmaps or pixmaps, used to display photos, icons,
static backgrounds, text characters extracted from font glyph sets, etc.). Addition-
ally, the appearance of each geometric primitive was controlled via specification
of attributes; in Microsoft APIs, the
brush
attribute specified how the interior of
a primitive should appear, and the
pen
attribute controlled how the primitive's
outline should appear.
For example, the simple clock image shown in Figure 2.3 is composed of four
primitives: an ellipse filled using a solid-gray brush, two polygons filled using a
solid-navy brush for the clock's hour and minute hands, and a red-pen line segment
for the second hand.
In the original GDI's simplest-usage scenario, the application uses integer
coordinates that map directly (one-to-one) to screen pixels, with the origin (0,0)
located in the upper-left corner of the canvas, and with
x
values increasing toward
the right and
y
values increasing toward the bottom.
The application specifies each primitive via a function (e.g.,
FillEllipse
)
that receives the integer geometry specifications along with appearance attributes.
(The GDI source code for this example application is available as part of the online
material for this chapter.) The specification is reminiscent of plotting on graph
paper; for example, the geometry of the gray circular clock face is passed to the
FillEllipse
function via this data pair:
Figure 2.3: Clock scene with GDI
coordinate-system overlay.
Center point: (150,150)
Bounding box (smallest axis-aligned enclosing rectangle): upper left at
(50,50), dimensions of 200
×
200
How large will this clock face appear when rendered onto the output device?
There's no definitive answer to that question. The displayed size depends on the
resolution
1
(e.g., dots per inch, or dpi) of the output device. Suppose our clock
application was originally designed for a 72dpi display screen. If the application
were tested on a higher-resolution device (e.g., a 300dpi printer or screen), the
clock's image would be smaller and possibly illegible. Conversely, if the target
display were changed to the small, low-resolution screen of an early-generation
smartphone, the image might become too big, with only a small portion of it
visible.
The raster graphics community solved this problem of
resolution depen-
dence
by borrowing ideas long present in vector graphics, using floating point to
support alternative coordinate systems that insulate geometry specification from
device-specific characteristics. In Section 2.4, we'll introduce and compare two
such coordinate systems:
physical
(based on actual units of measurement like
1. This use of the term “resolution” contrasts with another common usage, the total num-
ber of display pixels (e.g., “LCD monitor with 2560
×
1440 resolution”).
