Graphics Reference
In-Depth Information
client area
(red in Figure 2.1) that is the interior of the window, by making calls
to the graphics platform API. The platform responds to those calls by driving the
GPU to produce the desired rendering.
Typically the application uses the client area for two purposes: Some por-
tion of the area is devoted to the application's user-interface (UI) controls, and
the remaining area contains the
viewport
that is used to display the rendering of
the
scene,
which is extracted or derived from the AM by the application's
scene
generator
module. As you can see in the diagram, the
UI generator
module that
generates the user interface is distinct from, and operates very differently from, the
scene generator, even though they both use the underlying 2D platform to drive
the display.
Our use of the terms “scene” and “viewport” for 2D may surprise those with
experience in 3D graphics, in which those terms have 3D-centric usages. In the 2D
domain, we use the term “scene” analogously to mean the collection of 2D shapes
that will be rendered to create a particular view of the AM. Note that the 2D
scene generator corresponds directly to the scene generator for 3D applications
that feeds a 3D platform to produce a rendering. Similarly, our 2D use of the
term “viewport”—to mean an area in which the scene's rendering will appear—is
consistent with 3D usage.
Consider an interior-design application that displays and enables editing of a
furniture layout. The application model records all data associated with a given
furniture layout, including nongraphical data such as manufacturer, model num-
ber, pricing, weight, and other physical characteristics. Some of this information
is needed to produce a graphical view of the model, and some is used only for
nongraphical functionality (e.g., purchasing). It is the task of the application's
scene generator to traverse the application model, extract or compute the geomet-
ric information relevant to the desired scene, and invoke the graphics platform API
to specify the scene for rendering.
The scene may contain a visualization of all the geometry described in the
application model or it may represent a subset (e.g., showing only one room of
the house being designed). Moreover, analogous to multiple views of databases,
the application may be able to provide multiple views using different presenta-
tion styles for the same geometric information (e.g., showing furniture either as
outlines or as shapes filled with textures simulating fabric or wood).
In the above example, the application model is inherently geometric. However,
in other applications the AM may contain no geometric data at all, as is typical
in
information visualization
applications. For example, consider a database stor-
ing population and GDP statistics for a set of countries. In this case, the scene
will often be a chart or graph, derived from the AM by the scene generator and
designed to present these statistics in an intuitive visualization. Other examples
of data visualization applications include organizational charts, weather data, and
voting patterns superimposed on a map background.
GUI platforms
Layout
managers
and smart
controls
• WPF
• Cocoa
UI Kit
• Swing
•
•
•
• SVG
Templates
and
reusability
•
Retained
Immediate
• GDI+
• Quartz
• HTML5
canvas
•
•
•
Floating-
point
coordinates
Integer
pixel
coordinates
• QuickDraw
• Orig. GDI
Graphics platforms have experienced the same low- to high-level evolution
(depicted in Figure 2.2) that has taken place in programming languages and soft-
ware development platforms. Each new generation of raster graphics platform has
offered an increasingly higher level of abstraction, absorbing common tasks that
previously were the responsibility of the application.
Figure 2.2: Evolution in level
of abstraction in commercial 2D
graphics platforms—from imme-
diate mode to retained mode.
