Graphics Reference
In-Depth Information
millimeters and typographic points) and abstract (with application-determined
semantics).
2.3.2 Immediate-Mode versus Retained-Mode
Platforms
The evolution from integer-based specification to floating point was shared by
all major 2D graphics platforms, but eventually a “split” occurred, creating two
architectures with different goals and functionality: immediate mode (IM) and
retained mode (RM).
The former category includes platforms (like Java's awt.Graphics2D, Apple's
Quartz, and the second-generation GDI+) that are thin layers providing efficient
access to graphics output devices. These lean platforms do not retain any record of
the primitives specified by the application. For example, when the FillEllipse
function of GDI+ is invoked, it immediately (thus the term “immediate mode”)
performs its task—mapping the ellipse's coordinates into device coordinates and
painting the appropriate pixels in the display buffer—and then returns control to
the application. At its most basic, the programmer's model for working in IM is
straightforward: To effect any change in the rendered image, the scene generator
traverses the application model to regenerate the set of primitives representing the
scene.
The lean nature of IM platforms makes them attractive to application develop-
ers who want to program as close to the graphics hardware as possible for maxi-
mum performance, or whose products must keep as small a resource footprint as
possible.
But other application developers look for platforms that offload as many
development tasks as possible. To satisfy these developers, RM platforms retain
a representation of the scene to be viewed/rendered in a special-purpose database
that we call a scene graph (discussed further in Chapters 6 and 16). As shown in
Figure 2.4, the application's UI and scene generators use the RM platform's API
to create the scene graph, and can specify changes incrementally by simply edit-
ing the scene graph. Any incremental change causes the RM platform's display
synchronizer to automatically update the rendering in the client area. Because it
retains the entire scene, the RM platform can take on many common tasks con-
cerning not only the display, but also user interaction (e.g., pick correlation, the
determination of which object is the target of a user click/tap, as described in
Section 16.2.10).
Graphics application
UI
generator
Scene
generator
Application
model
Retained-mode
graphics platform
API: Create
graphics
objects
API: Modify
scene
graph
Scene
graph
All RM packages can be traced back to Sketchpad [Sut63], Ivan Sutherland's
pioneering project from the early 1960s, which launched the field of interactive
graphics. Sketchpad supported the creation of master templates, which could be
instantiated one or more times onto the canvas to construct a scene. Each template
was a group of primitives and possibly instances of subordinate templates, bundled
to compose a single unified graphics object. Each instance could be geometrically
transformed—that is, positioned, oriented, and scaled—but in all other respects,
the instance retained the appearance of its master, and changes to the master would
immediately be reflected in all instances.
These key ideas from Sketchpad survive in all modern RM packages, mak-
ing these platforms excellent foundations for creating user interfaces. UI con-
trols (also known as widgets) are templated objects that, as an integrated collec-
tion, have an inherent, consistent look and feel. In this commonly used phrase,
Display
synchronizer
App client area
Figure 2.4: Schematic of a graph-
ics application atop a retained-
mode platform storing a scene
graph.
 
 
 
Search WWH ::




Custom Search