Graphics Reference
In-Depth Information
the word “look” refers to the graphical design/appearance (size, shape, font,
coloring, drop shadow, etc.). The word “feel” pertains to the controls' dynamic
behaviors, typically in response to user interaction, which can be subdivided
into built-in automated feedback behaviors and semantic/application behaviors.
Examples of built-in feedback include the graying-out of a control that is cur-
rently disabled, the glow highlighting of a button when the pointer enters its
region, and the display of a blinking cursor when the user is typing into a
control's text box. These feedback behaviors often include nice-looking anima-
tions, performed by the platform with no application involvement. Of course,
the application must get involved when the user initiates an application action
(e.g., clicks a button to submit a form for processing). To spark such activity, the
RM simply invokes the application callback function attached to the manipulated
control.
Most RM UI platforms also include layout managers that spatially arrange
controls in a pleasing and organized way, with consistent dimensions and spacing,
and that provide for automatic revision of the layout in reaction to programmatic
or user-initiated changes in the size or shape of the UI region.
A well-designed set of UI controls requires significant work by a team with
expertise in graphic and UI design; it is no small feat to construct a pleasing and
intuitive UI framework. Rendering and laying out the UI, and handling user inter-
action, make up a large portion of the work involved in building an interactive
application, so it should be no surprise that the use of RM UI platforms, which
offload many tasks as described above, is pervasive. Indeed, it would be hard to
find a modern 2D application that does not use an RM UI platform to handle
virtually all of its needs for interaction through components such as menus, but-
tons, scroll bars, status bars, dialog boxes, and gauges/dials.
In contrast with retained mode's high popularity in the 2D domain, its use in
3D is less pervasive. Even though 3D RM platforms offer powerful features—
such as simplifying hierarchical modeling and rigid-body animation—these
features carry a high resource cost. We address this topic in greater detail in
Chapter 16.
2.3.3 Procedural versus Declarative Specification
Traditionally, each graphics platform has provided one of the following tech-
niques to developers for the purpose of specification of user interfaces and/or
scenes:
Software
engineers
Designers/
artists
Development tools
Procedural code written in an imperative programming language (typ-
ically, but not necessarily, object-oriented), interfacing with the display
devices via any of dozens of graphics APIs, such as Java Swing, Mac OS
X Cocoa, Microsoft WPF or DirectX, Linux Qt or GTK, etc.
Declarative specification expressed in a markup language, such as SVG
or XAML
XAML
API
One of WPF's distinguishing characteristics is that it offers developers
a choice of specification techniques, as shown in Figure 2.5 and described
below.
Figure 2.5: WPF application/
developer interface layers.
 
 
Search WWH ::




Custom Search