An Introduction to Windows Presentation Foundation

 

David F. Sklar, Consultant
Andy van Dam, Brown University

September 2005

Applies to
   Microsoft Prerelease Software WinFX Runtime Components (September PDC 2005 Build)

Summary: Introduces the features of Windows Presentation Foundation, formerly code-named "Avalon," part of the new Windows Vista platform. (32 printed pages)

Contents

Acknowledgements
1. Why a New Win32 Platform?
2. Enriching the User Experience
3. The Application-Development Experience
4. Preparing for the Windows Presentation Foundation

The purpose of this paper is to introduce you to a number of the concepts and features of the Windows Presentation Foundation (WPF, formerly code-named "Avalon"), part of the Windows Vista developer platform, and the foundation for the next generation of Windows applications and content.

WPF enables software developers to achieve a new level of quality in the "User Experience" (UX) aspect of applications. Developers will be able to use WPF to build applications similar to those they construct atop Win32 today... but they will also use WPF to create and display media-rich interactive content, animations, and traditional documents.

With the initial release of WPF, developers will be able to write applications that match the functionality and experience that is prevalent for Win32 or DHTML applications and content. Twitch games and high-end scientific visualization/CAD applications, typically the focus of Direct3D developers, are not within the scope for WPF in its first release; however, even in those application domains, there are ways that WPF (particularly its support for documents, as described in section 2.11) can be used to add UI value.

The WPF is not just about graphics. Its coverage of all common forms of presentation—UI, media, vector graphics, and documents—represents a degree of unification that is new to the Windows platform. The "silo" effect found in today's current disjoint set of client-side technologies has been replaced by a single managed set of classes providing a consistent set of base properties and methods. The result is an unprecedented ability to "mix and match" UI controls, content (document and media), and vector graphics in a seamless manner.

WPF also has features intended to streamline the development process, by reducing the amount of procedural code in application specification, and by enabling a greater and more direct collaboration by members of the development team—UI designers and graphic artists, as well as software engineers. The fundamental technology behind this marriage of design and implementation is a declarative markup language called XAML. Section 3 introduces the layered application-specification methodology that provides this flexibility.

By building the WPF atop the cutting-edge Direct3D graphics engine, Microsoft makes it possible for everyday applications to take advantage of the rapidly evolving power of graphics hardware, without the need for direct access to the Direct3D layer. WPF applications will automatically benefit from the optimization capabilities found in Direct3D now and in the future.

In the first section, we summarize the motivation behind Microsoft's decision to build its next-generation development platform. Thereafter, we present introductions to key components of the platform, first those in the user-experience realm, then those in the developer-experience realm. Keep in mind that taken individually, some of these components or features may be only an incremental improvement over the status quo. To appreciate the power of this platform, it is important to note that these features and techniques have not been available "under one roof" before, and it is this new level of integration that will give WPF development teams an unprecedented ability to efficiently create applications with high UX value.

Acknowledgements

The authors thank Pablo Fernicola, WPF Group Program Manager, for his role as guide and mentor during the research phase, and for his thorough reviewing and editing activities that produced significant improvements to the accuracy and readability of this article.

1. Why a New Win32 Platform?

For two decades, the Microsoft Windows graphics platform provided primarily by the GDI and User libraries (hereafter called "the original GDI platform" or simply "GDI") has provided the foundation for nearly all of the successful Windows applications. Many massive projects that have been enjoying great commercial success—like Microsoft's Office and Adobe's Creative Suite—and some very important embeddable technologies—like the rendering engine of Internet Explorer—are built atop graphics libraries that use this tried-and-true foundation.

These applications are not facing any "brick wall"... there's no imminent event that will cause GDI to suddenly fail to perform for them.

So, why has Microsoft invested in the construction of a completely new foundation for client applications? And why should an application developer well-versed in and comfortable with the existing Microsoft client platforms—original GDI, GDI+, Windows Forms—evaluate and consider the new WPF for future client projects?

1.1 Two Decades of Evolution

Fundamental to the pace of technological progress in Information Technology in the past twenty years—and its extraordinary societal and economic impact—have been the evolution of computer hardware; increases in computer literacy; and the cultural, commercial, and media explosion resulting from the advent of the World Wide Web.

Some key evolutions that have occurred since the introduction of the classic GDI platform:

• We have seen remarkable advances in speed of processors, power of graphics hardware, and affordability of RAM and secondary storage.
  GDI and the original Windows desktop were designed to be as resource-lean as possible, a requirement of any software of that era. Thus, when today's high-powered CPUs are running applications based on the original GDI, they are still rendering a largely "vanilla" user experience, not taking full advantage of the hardware's capabilities.
• The "Digital Lifestyle" has become pervasive.
  Having started with email and primarily textual web content—and then later having extended deep into our personal lives via digital photographs, video, and music—the Digital Lifestyle is now widespread in the community of computer users. This puts new demands on software developers, as lifestyle applications require richer and more engrossing online experiences.
• Television programs and websites have evolved to provide extremely rich visual experiences. CNN's introduction of the innovative Headline News format in 2001 gave television an impressive boost in UX, with its "live" backgrounds, framed news tickers, "windowed" anchorpersons, and multiple video feeds. That format raised the bar on the definition of an "engaging experience" for all types of information presentation, and in short order, TV news and sports shows on all major networks followed suit by incorporating similar features. In parallel, websites have continued to become more animated and media-rich, using some of the features found in TV and the print media as well as introducing new techniques not available on those traditional platforms. Yet, outside of computer gaming, the UX of a typical software application has not kept up with the UX of the typical well-regarded TV program or Web site.
• High-quality document presentation is in demand.
  It is no longer acceptable for the online presentation of information—whether a facsimile of a paper document, "help text" for an application, or a PowerPoint presentation—to suffer from primitive typography and aliased ("jagged") graphics.
• The variety in target display hardware has grown.
  When GDI was designed, desktops with monitors in the 70-100dpi resolution range were dominant. Now, there are high-resolution screens used by graphic artists, and tiny low-resolution screens on the ever-shrinking handheld devices; however, UIs based on original GDI are still pixel-size dependent and thus suffer from usability issues on resolutions at either extreme.

To take proper advantage of ever-increasing hardware capability and to address growing demands for more powerful platforms and applications, as well as needs for ever higher quality content and user experiences, Microsoft has introduced a number of important advances addressing new requirements set by the developer community:

• .NET introduced "managed code" and the Common Language Runtime, which provide a state-of-the-art general-purpose platform for development and deployment—with cross-language integration, language-independent typing system, self-describing assembly packaging (simplifying deployment/versioning activities), and integrated security services.
• The rapidly evolving Direct3D system harnesses new features and higher speeds in the products of the fast-moving graphics-hardware industry.
• GDI+ provided an expanded set of graphics primitives and a number of improvements in rendering quality.
• Windows Forms was released to provide both a richer user experience and a streamlined development/deployment paradigm for the growing class of "smart-client" applications delivered via the web, as well as managed access to GDI+ functionality.
• Microsoft's work with the W3C on Dynamic HTML and JavaScript provided a foundation for the very earliest set of powerful client-side Web applications.
• The Developers' Experience has been improved significantly by the evolution of the Visual Studio suite—offering a consistent cross-language experience, integrated resource management and document access, and coding aids like IntelliSense.

As a result of the successes of these various projects, Microsoft was facing two distinct but related challenges:

• Microsoft's assets included a set of distinct technologies and advances (as listed above) embraced by the developer community, providing state-of-the-art features and solving age-old problems—but for the most part independent of (and often incompatible or very-loosely integrated with) the GDI platform.
• The Windows platform needed to evolve in order to provide today's ever-more-sophisticated computer users with the rich user experience they have come to expect, but maintain compatibility for existing applications and content.

The Windows Presentation Foundation was created to address these two challenges.

1.2 Goals for the next-generation client foundation

The name that Microsoft chose for this new platform gives a good indication of the wide scope of functionality that is being unified under a single umbrella. The use of the term "presentation"—rather than the traditional term "graphics"—expresses the wide variety of user experiences this platform can manage:

• The classic standalone interactive application
• The relatively-new breed of Web-based "navigation" applications
• 2-D and 3-D vector graphics
• Media presentations—from images, to streaming video and audio, to vector-graphics animations
• Document delivery, consumption, and printing

With the scope of the functionality thus decided, the architects decided on a key set of design goals:

• The system would build upon the .NET and Direct3-D technologies:
• The API would be 100% managed code, to glean the many development/deployment benefits of that architecture, and to take advantage of the investment Microsoft has made in the construction of .NET framework.
• The graphics pipeline would benefit from the continuing evolution on the Direct3D platform, and thus keep up with developments in graphics hardware.
• The quality of presentation in all arenas—typography, vector graphics, image, and media—would be the highest possible, taking advantage of the features found in modern graphics hardware.
• The various services to be combined into this single platform would be integrated to the fullest extent, eliminating the awkward "loose integration" (ability to embed but not to control) that was in some cases the only level of compatibility between Microsoft's disparate technologies.
• The development environment would include significant advances to streamline the development process, facilitate rapid-prototyping, and make it easier for programmers and designers/artists to work together. To achieve this goal, WPF would introduce a powerful declarative alternative to the traditional procedural-code method of application specification, to empower non-programmers and to provide a "exchange format" for development tools.

Below we provide an overview of the feature set of WPF, divided into two categories:

• Features designed to enhance the User Experience
• Features that streamline and empower development teams, including both software engineers and graphics designers/artists.

2. Enriching the User Experience

This section presents the WPF features that empower developers to provide a higher level of quality in the User Experience. There are three levels of "learning curve" that will be experienced by developers moving to WPF to harness these features:

Lower
Many of these improvements come "for free"—simply by virtue of building atop this platform. Thus, the only learning curve relates to becoming acquainted with the managed-code platform, the basics of WPF development , and the object classes that provide the equivalent of GDI functionality.

Medium
Other features/improvements will require engineers to learn a new principle, study the methods/properties of a new class, or adopt a simple technique.

Higher
And a few have a learning curve that is non-trivial, requiring some degree of self-education and iterative experimentation.

In the feature descriptions below, we include this "learning-curve" measure (Lower, Medium, or Higher) to provide a preview of the level of effort involved in learning how to obtain the benefits of each feature.

2.1 Overview of Application Specification

In section 3, we will describe the development environment in detail, but for this section it is important to know that there are multiple layers at which WPF application specification can occur.

• The lowest layer is of course traditional programming with an API, in this case a managed-code language-independent API built atop the .NET framework. Only software engineers will work at this level.

• Above that layer is an alternate way to specify a significant subset of the API functionality, especially regarding UI layout, vector graphics, documents, and animation. Both engineers and designers may work at this level.

  This second layer is based on a declarative language called XAML (Extensible Markup Language) whose syntax is that of XML. Because it is higher-level, and thus more concise, XAML is used for our implementation examples. Those familiar with HTML syntax should find XAML syntax comfortable.

• Forming the highest layer is a growing set of tools (interactive editing systems and batch-processing converter utilities) that use XAML as a transfer language. As the set of tools grows, the need for developers to work directly with XAML data will be reduced significantly.

2.2 Basic 2-D Graphics Model

It is not difficult for developers who are experienced in GDI and GDI+ to adapt to the WPF 2-D graphics model. Many of its basic characteristics are just slight variations from those of GDI:

• The coordinate system is oriented similarly, with "y" axis pointing down. However, WPF coordinates are double-precision floating-point instead of integers, as part of its resolution-independent nature.
• In 2-D space, there is a third "depth" coordinate implied by the order in which the 2-D objects are specified, used to determine how overlapped shapes are arranged. So it may be helpful to think of the graphics as being "two-and-a-half dimensional".
• To facilitate the display of 3-D scenes on 2-D devices, WPF provides a "viewport" primitive, which is a "canvas" on which 3-D scenes can be projected as part of the rendering pipeline.

But there is one key difference between the WPF and GDI(+) models, which is the essential component behind the most useful advances provided by WPF. This component is retained-mode graphics described in section 2.3 below.

2.3 Retained-mode Graphics

In the GDI/GDI+ paradigm, the application must respond to "invalidation" events in order to repaint parts of the image damaged by previously overlapping images. This burden exists because GDI's graphics model is primarily a "pixel painter"—once a primitive like an ellipse is rendered, GDI "forgets" the primitive. The application must retain the state (geometry, formatting attributes, etc.) of all these graphic objects in order to be able to repaint the scene. A great deal of code in a graphics-intensive GDI application is dedicated to retaining the graphics data and doing the "reactive repainting" activities.

Why is it that GDI programmers never have to worry about maintaining the images of user-interface controls? Because controls are retained-mode graphics—they are objects stored in the underlying graphics system, with policies regarding appearance and behavior. The application does not draw them; rather, the application specifies them, by positioning them and setting their properties (e.g. button-label text, or background color). The burden of maintaining the image of the control is borne by the graphics platform itself, not by the application.

Thus, the concept of "retained-mode graphics" is not new to those with GDI/Win32 experience. But, what is new is the idea of a platform in which all graphic objects are retained. And that is the case in WPF. In addition to the UI controls and media primitives, the WPF's 2-D Shape primitives (rectangles, ellipses, paths, etc.) and 3-D modeling primitives are retained objects. The WPF application does not draw a scene, but rather constructs a hierarchy of components (called a visual tree) composed of regions controlled by layout managers, UI controls, and shape primitives. The application treats these components as data, not as pixels. For example, the application resizes a shape by changing its geometry properties, or makes a shape slowly disappear by gradually decreasing its opacity property. The underlying graphics system does all the work to ensure the image matches the visual tree.

2.4 UI Controls and Layout

High-quality rendering (learning curve level: Lower)

Application developers who use the WPF to build a simple forms-based or data-visualization application will obtain great improvement in UI appearance "for free" (i.e. using the same techniques common in Win32 development). Their applications will instantly benefit from the following improvements in the rendering pipeline, which affect all of WPF's controls uniformly and consistently:

• Higher-quality typography—via built-in support for subpixel ClearType and OpenType (including advanced features like contextual ligatures) used for all text, including text in UI controls
• Resolution independence
• Anti-aliasing, eliminating the "jagged" edges of the rendering of diagonal or curved lines
• Higher performance in drawing and refreshing, due to WPF's better use of the underlying graphics hardware

Typical GDI "check-box palette"	The same palette's appearance in WPF

Figure 1. Appearance improvements in one of the common UI controls, shown normal size and at 400% to highlight WPF's use of anti-aliasing and gradient shading

Layout Management (Learning-curve Level: Medium)

Only recently, with Windows Forms, has Microsoft provided adaptive layout services. Prior to that, the application designer placed controls in a container "canvas" using absolute positioning and sizing. It was expensive to write custom layout algorithms to adapt to changes in screen "real-estate" or resolution, and thus the typical GDI application contains dialog boxes and control palettes that have completely "hardwired" layouts, reducing usability at extreme (low or high) resolutions, and hampering accessibility.

To repair that problem, Windows Forms provided layout managers that allowed designers to:

• Perform relative positioning (anchoring a control to one of its neighbors)
• Specify which objects in a layout should adapt to changes in real-estate, versus which ones should have locked sizes
• Easily generate certain common layouts like table/grid

WPF builds upon the lessons learned from Windows Forms with its set of Panel containers that include these features:

• Includes a richer palette of built-in layout algorithms
• Can be nested arbitrarily to produce powerful adaptive layouts
• Can be treated as a unified single entity for the purpose of formatting—e.g. a panel container can be given translucency, or rotated/skewed/scaled by a 2-D transform, etc., and the effect is applied to the entire UI layout contained within. (See figure 3 for an example.)
• Is based on a platform that programmers can use to construct custom layout managers

Our first XAML example shows the specification of the list of checkboxes shown in Figure 1. The panel used is the "StackPanel" layout manager, which places its children in a vertical stack from top to bottom:

<StackPanel Background='lightgray'>
   <CheckBox Margin='2'>Use replacement table</CheckBox>
   <CheckBox Margin='2'>Correct TWo INitial CApitals</CheckBox>
   <CheckBox Margin='2'>Capitalize first letter of every sentence</CheckBox>

    <!-- This checkbox has a TextBlock child to facilitate formatting changes -->
    <CheckBox Margin='2'>
       <TextBlock>Automatic 
          <Bold>bold</Bold>
          and 
          <Underline>underline</Underline>
       </TextBlock>
    </CheckBox>

    <CheckBox Margin='2'>URL Recognition</CheckBox>
  
</StackPanel>

2.5 2-D Vector Graphics

Appearance improvements that are "free of charge." (Learning-curve level: Lower)

GDI+ adopters saw a significant leap in the quality of 2-D graphics when they first made the jump from the original GDI platform. Any developers still working with GDI will be blessed with the same—and a few more—improvements when they move to the WPF graphics platform. The key improvements regarding shapes are:

• Resolution independence for full scalability
• Anti-aliasing in rendering (demonstrated via the rounded-rectangle edges in Figure 2)
• Greater level of hardware acceleration

New graphics techniques. (Learning-curve level from original GDI: Medium)

Additionally, WPF provides these features, which require classic-GDI developers to learn several new techniques that were introduced in GDI+:

• Gradient fills—filling an area with a range of colors varying gradually from a given "start" color to a given "end" color (demonstrated in the WPF part of Figure 2)
• Graphic paths, including spline curves
• Translucency (called "alpha-blending" in GDI+)
• Transformations (skewing, rotating, scaling, translating/moving)

Developers who add these techniques to their palette will be able to easily produce a large number of graphic effects that were extremely difficult to program in the original GDI.

FIGURE 2. GDI vs. WPF renderings of a scene composed of rounded rectangles, text, and an image. Shown at original size and at 400% to highlight anti-aliasing and gradients now available in WPF.

The XAML that generates the WPF scene (the right half) of figure 2 is shown below, and demonstrates:

• Use of nested layout managers

• Creating, formatting, and transforming basic 2-D shapes, text, and media

  <!--
  Top-level layout manager is a one-celled “Grid”,
  which is perfect for placing a set of children on top of each other,
  vertically/horizontally centered relative to each other. -->
  <Grid>
  
     <!-- 
     THE GREY ROUNDED RECTANGLE “SHADOW”
     Instead of using opaque grey, black at 30% opacity is used.
     If this scene is placed atop other content, the shadow
     portion will allow overlapped content to be seen. -->
    <Rectangle
        RadiusX="10" RadiusY="10"
        Fill="Black" Opacity=".3"
        >
  
      <!-- 
           This 2-D translation
           specification offsets this rectangle
           by 3 units to the right and down
           to place it as a shadow of the green rounded rect -->
      <Rectangle.RenderTransform>
         <TranslateTransform X="3" Y="3"/>
      </Rectangle.RenderTransform>
    </Rectangle>
  
  
     <!-- 
      THE GREEN ROUNDED RECTANGLE WITH GRADIENT FILL -->
    <Rectangle
           RadiusX="10" RadiusY="10" 
           Fill="VerticalGradient #3a3 #afa"
        />
  
  
  <!-- 
        A NESTED HORIZONTAL STACKPANEL LAYOUT MANAGER
        IS USED TO PLACE THE IMAGE AND TEXT LABEL SIDE-BY-SIDE -->
     <StackPanel Orientation='Horizontal' Margin='8,4,8,4'>
  
           <!--
            EXPLICIT WIDTH SETTING ON THE IMAGE TAG
            ACTIVATES HIGH-QUALITY “SMOOTH” RESCALING -->
        <Image Margin='1'
               Source="checkmark2.gif" 
               Width='20'/>
  
        <TextBlock Margin='1'
                   FontFamily="Verdana"
                   FontSize="14" 
                   Foreground="Black">Vote</TextBlock>
  
     </StackPanel>
  
  </Grid> 
  

Applying effects to aggregates. (Learning-curve level: Medium)

As noted earlier, an entire layout of controls can be treated as a unified single entity for the purpose of formatting or transforming.

For example: consider this classic problem with high-functionality editing applications. Often, it is impossible for the application to show both the complete set of tool palettes and a comfortably large drawing area. The user thus spends time and energy hiding/re-showing (or docking/moving) the various tool palettes, and would benefit from the ability to shrink/expand palettes without any loss in interactive functionality.

WPFs consistent treatment of all 2-D graphic objects—including UI controls and even entire UI layouts—makes trivial the implementation of such a technique. Any UI layout, no matter how complex, can be subjected to any kind of 2-D transformation (even rotated and skewed) without losing its interactive behavior. An example of the palette-scaling technique is in the interface of Microsoft's Expression Interactive Designer, illustrated in figure 3 below. This technique requires nothing more than the attachment of a scale transform to the layout manager that is responsible for the stack of palette areas.

In figure 3(a), the tool palette is displayed to the user at normal size. The slider control ("Workspace Zoom") grants the user a very fine level of control over the palette's size.

Figure 3(b) shows the user interface after the user scales the palette down ("zooms out"). The layout automatically adjusts to show more of the drawing area (visible at left). The entire palette is available, with all its controls still "live". An experienced user of the application can use this reduced-size palette and takes advantage of the increased size of the drawing area. When used in combination with translucency and/or traditional "show/hide" and "dock/undock" support, high-functionality editing applications can ameliorate the classic "real-estate" problem.

Note that a visually handicapped user can scale up ("zoom in") for a better view of the tools, making this feature a great accessibility aid as well.

Figure 3(a)

Figure 3(b)

2.6    Imaging

(Learning-curve level: Medium)

With the growth in digital photography, imaging has become more relevant to application and content development. WPF provides a few imaging advances that raise the level of image-related services and add new levels of extensibility

• Hardware acceleration for imaging operations—WPF maps images to the 3-D graphics pipeline, enabling scaling, rotation, and other operations to be performed on the video graphics card. This benefit accrues even to Web-based WPF applications.
• Extensible CODECs—Although WPF provides built-in support for an extensive set of image formats, it also provides an extensibility mechanism for developers to innovate beyond the functionality provided by the platform. This is especially relevant for developers that have a proprietary image format, which they want to be relevant and accessible to a larger number of end users and developers, such as the formats used in most digital cameras (RAW formats).
• Extensible Metadata—In the same manner that developers can extend the image formats available to applications, they can also extend the metadata formats used to annotate images.

2.7 Media

(Learning-curve level: Medium)

Many different types of media—including video, audio, and images—are fully integrated into WPF. Any manipulation that can be applied to any 2-D shape or control can be applied to media as well. Moreover, synchronization can be achieved at fine granularity, because the timeline for media can be manipulated (e.g. paused, stopped, started) by any other part of the application—via event handlers, application logic, etc.

The visual effects made possible by complete integration of the media controls are impressive and form the basis of some of the most compelling demos being shown during the rollout of WPF. Video playback is no longer limited to a rectangular surface appearing parallel to the computer screen; but rather it can be:

• Positioned or animated in 3-D space using the "2-D-on-3-D" approach described below in section 2.8
• Skewed, rotated, and/or scaled using the 2-D vector-graphics transformation properties
• Made translucent
• Clipped by an arbitrary 2-D geometrical figure (e.g. supporting the effect of a porthole through which a video of underwater scenes are being displayed)

2.8 3-D Graphics, and "2-D-on-3-D"

(Learning-curve level: Higher)

The term "3-D graphics" typically brings to mind the kind of activities associated with CAD/CAM and video games: the specification of a "scene" of models positioned in 3-D space, the wrapping of "skins" (textures, materials) on the modeled objects, the placement of lights, the positioning of a camera, and finally the projection of the scene onto a 2-D viewport.

WPF does indeed include all of the components of that pipeline, but in its first release it will not have as much 3-D functionality as packages like Direct3D and OpenGL. Future versions may have full 3-D functionality; however, if you are currently a Direct3D programmer, you will likely continue to use Direct3D in the immediate future. WPF is not a replacement for Direct3D for graphics-intensive applications like "twitch games."

One of the reasons that the traditional 3-D modeling/rendering pipeline is not yet "up to speed" is that the 3-D support in WPF will typically be used in a very non-traditional way: to facilitate what we call "2-D-on-3-D" imaging.

The "skin" applied to a planar face on a 3-D model can be any tree of 2-D components, and thus an application can "map" 2-D scenes onto the faces of 3-D objects, including:

• A video (see the figure below)
• A static image from a JPEG
• A 2-D scene constructed from shape objects
• A complete user-interface layout, e.g. the output of a medical-monitoring system

Figure 4. Example of 2-D-on-3-D: video mapped onto faces of a cube

Thus, by manipulating the camera and/or the 3-D model, these types of 2-D scenes—which have long been limited to flat rendering on the screen's planar face—can be made to "fly" in 3-D space. Moreover, if the 2-D scene is animated (e.g., a movie, or a UI layout includes some animated component), those dynamics are not lost; the projection of a 2-D scene onto a 3-D model is updated automatically to keep the image in sync with the 2-D scene's state.

(Note: the 2-D scene is not "live" in the sense of being able to respond to user actions; it is live only in an output sense.)

This feature can be used for many types of UX enhancements—for example, an online music store could render a user's "wishlist" or shopping cart as a 3-D view of CD cases standing on a shelf, simply by projecting 2-D album-cover images onto 3-D models

2.9 Animation

(Learning-curve level: Higher)

This term is usually used to refer to the construction of "movies"—even if just a repeating short sequence of action on a website banner ad. And indeed the animation facilities in WPF can be used to create these kinds of sequences with its support for keyframe-style animation.

But the prototypical use for WPF animation is more tied to user interfaces—how UI controls can show changes in state in a more attractive way, how the backgrounds being a user interface can be more dynamic, etc.

Windows Vista provides several examples of the use of WPF animation to improve UI dynamics. In Windows Vista's new desktop, dynamic feedbacks "glide" into place instead being instantly rendered. When a button receives the mouse focus, for example, it gradually turns on its focus glow. When a window is minimized, the entire window—still "live"—glides into position in the bottom bar, shrinking as it moves into its minimized representation. Throughout the Vista user experience, UI objects gently change state instead of "jolting" into new states, to preserve visual continuity.

This kind of animation—"UI animation"—is rarely found in GDI applications because the graphics platform offers absolutely no assistance. Because GDI graphics are not retained-mode, they are unknown to the graphics system once drawn, so performing dynamics upon them requires a significant amount of complex application code.

However, the use of retained-mode graphics allows WPF to provide tools for animation, and its tools meet the needs of both UI and keyframe animations. And because XAML supports animation specifications, it is possible for designers to create, test, and deploy many kinds of rich animation without the need for programming work.

"UI animations" are performed via property animation. As mentioned previously, all 2-D shapes, 3-D models, and UI controls are objects with geometric and appearance properties. Property automation is simply the specification that a particular property's value should be changed from a particular value to some other value over some duration in time.

Let's examine a typical use of animation. Consider a variation of our "Vote" button in which the checkmark is normally "faint" (30% opacity as illustrated below left), but responds to mouse focus (mouse entering the scene's region) by having the checkmark move from faint to strong (100% opacity, as illustrated below right) over the course of 0.3 seconds.

Figure 5. Example of UI animation

This feedback style can be achieved via property animation of the opacity of the checkmark image. To implement this, we modify the XAML shown in association with Figure 2.

First, the image object's specification needs to be changed to:

• Initially set opacity at 30%
• Give the image object a name that can be used to refer to it in the animation specification

<Image Margin='1'

Name='CheckImage' Opacity='0.3'

Source="checkmark2.gif" Width='20'/>

Then, triggers are specified on the grid layout manager to specify desired responses to mouse-enter and mouse-leave events. Each trigger's "action" specifies the desired property animation:

    <Grid.Triggers>

      <!-- Upon mouse entry, 
           animate the checkbox image's opacity 
           to 1.0 in 0.3 seconds -->
      <EventTrigger RoutedEvent='Rectangle.MouseEnter'>
        <EventTrigger.Actions>
          <BeginStoryboard><Storyboard>
              <DoubleAnimation 
                Storyboard.TargetName="CheckImage"
                Storyboard.TargetProperty="Opacity"
                To="1.0" Duration="0:0:0.3"/>
            </Storyboard></BeginStoryboard>
        </EventTrigger.Actions>
      </EventTrigger>

      <!-- Upon mouse leave, 
           animate the checkbox image's opacity 
           back to 0.3 in 0.3 seconds -->
      <EventTrigger RoutedEvent='Rectangle.MouseLeave'>
        <EventTrigger.Actions>
          <BeginStoryboard><Storyboard>
              <DoubleAnimation 
                Storyboard.TargetName="CheckImage"
                Storyboard.TargetProperty="Opacity"
                To="0.3" Duration="0:0:0.3"/>
            </Storyboard></BeginStoryboard>
        </EventTrigger.Actions>
      </EventTrigger>

    </Grid.Triggers>

In this example, a formatting property is being animated. But keep in mind: any property—including geometry transformations—can be manipulated by property animation. Thus, animations can also cause non-instantaneous movement, rotation, and even skewing.

2.10 Control Composition

(Learning-curve level: Medium)

A WPF UI control is nothing more than a unified collection of 2-D shapes sharing common event/feedback handling. Thus, creating custom appearances for any of the built-in controls is performed with the same techniques used for specifying and positioning 2-D shapes, and thus can be done in XAML by non-programmers.

As an example, consider the default appearance for the Button control, which includes feedback animations like the orange mouse-focus highlight:

<!-- See figure 6 for the resulting display --> 
<Button>Vote</Button> 

Figure 6. WPF's default appearance, with mouse-focus highlighting, for the push-button control

If we would like to create a "Vote" button that has the look of the "checkmark" vote button designed earlier in this section, without loss of event handling and feedback support like the mouse-focus highlighting, we simply specify a layout of 2-D vector graphics inside the <Button> tag instead of merely specifying label text.

The resulting control (shown in figure 7) is a union of the standard button frame (with its feedback animations) and the custom look of our "checkmark" button.

Figure 7. A customized appearance, with mouse-focus highlighting, for the push-button control

This type of customization can be specified in XAML code by a designer, without the need for any work at the API level:

<!-- See Figure 7 for the resulting display -->

<Button>

  <!-- Inside the button tag, we specify an arbitrary "visual tree" 
       of layout and vector graphics... instead of specifying just the 
       text label. -->

  <Grid>

    <!-- THE GREEN ROUNDED RECTANGLE -->
    <Rectangle
      Fill="VerticalGradient #3a3 #afa"
      />

    <!-- A NESTED DOCK PANEL TO CONTAIN THE LABEL -->
    <DockPanel Margin='8,4,8,4'>
      <Image Margin='1'
        Source="checkmark2.gif" Width='20'/>
        
      <TextBlock Margin='1'
        FontFamily="Verdana" FontSize="14" 
        Foreground="Black">Vote</TextBlock>

    </DockPanel>

  </Grid>

</Button>

This example shows customization of just a single control instance, with retention of most of the control's "native" properties. Much more powerful types of customization are discussed later in section 3.2.

2.11 Documents

(Learning-curve level: Higher)

For many years, the "bread-and-butter" widget for on-line document presentation has been the embedded Web browser control—the core text-display technology for applications like SDK viewers, MS Help, etc.

WPF raises the level of quality in document presentation to a state-of-the-art level with a rich set of document features, which satisfy these application requirements:

• On-line document presentation
• Fixed-page (page fidelity) storage, transmission, and presentation
• Hardcopy generation

Of course, the display support has all of the typography improvements that are across-the-board in WPF as mentioned earlier. And the viewing widgets are fully integrated WPF controls that thus can be "transformed" for special user experiences (e.g. shown rotated or mapped to a 3-D surface).

To make a quantum leap in quality required a richer document specification. Thus, XAML includes functionality for the specification of document content.

WPF divides the universe of documents into two domains, and provides distinct support for both, relying on the same core services to provide consistent quality and performance.

2.11.1 — Reflowable ("adaptive") documents

A WPF reflowable document is much more than just a linear presentation of prose, static images, and structured tables. You can think of these as "kitchen-sink" documents — absolutely any visual object in the WPF universe can be placed inside a reflowable document for on-line display, including live user-interface layouts and controls. For example, one can imagine a help-system viewer that shows embedded live demos of illustrated techniques, living side-by-side on the same page with the text describing the technique.

Why are these types of documents called "adaptive"? Online document renderers have always been required to adapt to the constraints of the screen real-estate allocated to them. HTML viewers adapt to available width by "reflowing" text, but for the most part, they do not taken available height into consideration. Thus, users have long been saddled with the metaphor of the "bottomless" page that must be scrolled through, sometimes "ad nauseum." The only way an application can relieve the reader from the "unbearably long page" syndrome is to divide the content into individual HTML fragments, and provide the necessary navigation links—often an unwanted burden on the content provider.

To solve this problem, the WPF built-in flow-document viewer (called the "SinglePageViewer" control) supports automatic "adaptive pagination" based on available height, and this solution to the bottomless-page problem also allows support for multi-column presentation options. The content providers need not embed any pagination or column "hints" in the document—this is "on-the-fly" formatting that starts with the text and formatting specifications within the document, and then paginates, "column-izes", and flows the text based on the current state of parameters such as width, height, "zoom" factor (for accessibility support), etc.

Users will be able to view these XAML-format documents in several ways, including WPF's built-in viewer control as well as a forthcoming IE plug-in. The WPF viewer offers the reader a rich set of tools for activities like searching, navigating, copying, etc.

Figure 8. Adaptive pagination and "column-izing" in the flow-document viewer control

(a). User zooms "out" to full extent—automatic three-column look, entire document visible:

(b). User zooms "in"**—repaginated to 2 pages, with 2-column appearance

(c). User zooms "in" and gives viewer less width—now 7 pages, with 1-column appearance

2.11.2—Fixed-format documents

Of course, there is a need to address the class of documents that must be rendered with full-page fidelity (exactly as specified by the content provider). Such documents need to support high-quality text, and embedded media, as well as "invisible" metadata to support digital signatures and rights management.

The flow-document representation described above—with its ability to include any type of presentation object, including "live" objects—is clearly not appropriate for the representation of fixed-format documents. Thus, WPF introduces another document-representation format called XPS (the XML Paper Specification, formerly code-named "Metro"). XPS is designed to support fixed-format documents with the same high level of integration and rendering quality, but additionally:

• XPS includes compression technology to facilitate transmission and archiving of these types of documents.
• XPS is also the new hardcopy platform ("print path") for the Vista era.

Content providers have three choices for generating XPS documents:

• If an organization already stores/produces content in XML (or any other highly structured format), it will need to construct a tool to convert the structured documents into XPS.
• An author who needs to export an XPS document from any Windows-based application can use the printer driver that will be provided by Microsoft, compatible with all modern versions of Windows
• And last: a new generation of applications, including the next version of Microsoft Office, will natively support the ability to save as or export to XPS.

The XPS viewer (shown below) is available as an embeddable WPF control, or as a plug-in that can be hosted directly by Internet Explorer. It offers a very high level of sophistication, supporting features often required for fixed-format documents in the business community, like digital-rights management and digital-signature capture.

Figure 9. The user interface of the fixed-document viewer control.

3. The Application-Development Experience

Improvements in the "application-development experience" comprise a second set of goals achieved by the new platform. And the role of programmer/coder is not the only one addressed by these enhancements; the empowerment of designers has been given significant emphasis.

3.1 Layered Application Specification

The WPF architecture expands the concept of an "API" by providing a choice of layers at which developers can perform specification.

Figure 10. How designers and engineers access WPF functionality

The three layers that form this "application/developer interface" are:

1. At the lowest level is the traditional "API"—the set of managed classes that provide all functionality. Programmers can use any of the managed languages (C#, C++, Visual Basic, etc.) to specify application appearance and behavior at this level. It is of course possible to create any WPF application solely at this level, but the other two levels in the interface provide massive improvements in efficiency, comfort, and "inclusion" of workers in non-programmer roles.

2. The second level provides an alternative way to specify a large subset of the functionality of the API, via constructs available in XAML. What is available at this level maps 1-to-1 with classes, methods, and properties in the API layer. The declarative nature of this alternative form of specification improves upon procedural specification in several areas: support for rapid prototyping, ease of use even by non-programmers, and support for automated generation (important for layer #3).

   Moreover, the subset of functionality available at this level offers more than just the layout of UI controls. It includes basic event handling, animation, data binding, and re-styling of built-in UI controls; thus, designers can construct "executable design specifications" in pure XAML. These executable programs will serve to demonstrate both appearance, fundamental interaction behaviors, and navigation/flow.

3. As with any language, even a declarative one, there is a learning curve associated with its use. This third level takes advantage of Microsoft's choice of XML (which is easily generated and parsed) as the basis for XAML. Here lie the tools that developers (in both roles) will use to generate XAML code—tools for drawing graphics, creating rich documents, laying out user interfaces, etc. A set of useful tools already exist or are announced (see table below), and many more will be forthcoming.

   As the set of XAML-based tools grows, more and more of the development process will be performed at this level, reducing the learning curve and thus expanding the sphere of workers who will be able to participate directly in the process of developing WPF applications.

Application	Product	Vendor
2-D graphics	"Acrylic" (code name)	Microsoft
3-D graphics	Zam 3-D	Electric Rain (www.erain.com)
2-D/3-D graphics and UI layout	Aurora Expression Interactive Designer	Mobiform Microsoft
Generation of XPS documents	Printer driver Office 12	Microsoft Microsoft

In addition, a vibrant developer community is contributing utilities—including a plugin for exporting XAML from Adobe Illustrator, and tools to convert from other 3-D formats to XAML.

All of these layers are at the development team's disposal, and each team will naturally converge on some modus operandi involving all of the layers to some extent.

Now let's talk about some of the features of the platform that are designed to empower developers to be more efficient in the software construction process... as well as to reach levels of functionality that were prohibitively expensive to reach previously.

3.2 Control Customization

In section 2.10, we introduced the technique of control composition, which provides a simple way to customize the appearance of an individual control by "populating" its content portion (e.g. the label of a push button) with an arbitrary visual tree. That technique can be used to achieve many effects that were not easy to achieve with GDI(+) controls... but it is not true customization since it does not allow modification of the control's built-in behavior, feedback mechanisms, keyboard handling, etc.

If there is a need to alter a control's appearance and behavior in a more radical way, a developer can use WPF support for control templates to perform the customization, in most cases without any need for programming at the API level.

In the GDI paradigm, a built-in UI control is a "black box" with restricted parameterized control over appearance. Any customization—however lightweight—beyond that supported by the available parameters requires a technique called "owner draw" that is difficult to learn and costly to implement.

WPF controls are "open boxes" in that they are constructed via the public set of 2-D primitives and layout managers, and the "default formula" for a control's construction is available to developers. A designer can examine the XAML representation of a control's default template, adjust it to achieve the desired look, and save the new template as a custom "style" for that control type. Then, when instantiating the control (in XAML or in a program), a reference to the custom style can be made, thus forcing the instance to adopt the custom look and feel.

The full power of this technique may not be obvious until one considers that a template is more than just the definition of a control's appearance (via a visual tree of panels and shapes) —the template also includes specifications of feedback dynamics (specified via triggers, property animations, and data bindings). Thus, wholly within XAML, a designer can re-design a built-in control even to the level of how it represents keyboard/mouse focus, how it responds to keyboard shortcuts, etc.

Of course, some types of customization—and the inventions of new control types that are not present at all in the built-in set—do require the use of API programming, and thus API-based techniques for customization are available. But the far simpler template-based approach should suffice for most customization needs.

3.3 Data Binding

In data-driven graphics applications, the activity of mapping data to UI controls is a very common one. Data flows in two directions in these mappings:

• Data in the application is "sent" to the UI, to construct or refresh a graphic representation of the data
• User interaction with the UI is "sent" to the application database, to facilitate user editing of data

Traditionally, these activities have been performed largely programmatically; for example, event-handler functions are registered with UI controls to watch for user interactions for the purpose of updating the application database.

WPF support for data binding provides for non-programmatic declarative specification of these mappings. Either programmatically or in XAML, developers can construct "conduits" between UI objects and data objects that automatically perform the data transfers to keep both objects in sync. The result is that a large part of an application's interactivity—the responses to user actions and the refreshing of information displays—can be fully automated.

One-way binding

In one-way binding, a GUI control is allowed to control a property value somewhere else in the application.

For example, consider a GUI to allow the user to control how two side-by-side regions share the available width. For prototyping purposes, let two shape primitives (a rectangle and an ellipse) represent the two regions. We can use a slider control to let the user control how much width is alloted to the region on the left side (the rectangle in our prototype).

<DockPanel
  xmlns="https://schemas.microsoft.com/winfx/avalon/2005"
  xmlns:x="https://schemas.microsoft.com/winfx/xaml/2005" >

   <!-- The slider will control the rectangle's width -->
   <Slider Name="TheSlider" Minimum="10"  Maximum="100" 
           DockPanel.Dock="Top"/>

   <!-- The rectangle's width is being controlled by the slider -->
   <Rectangle 
      Fill="Black"
      Width="{BindingElementName=TheSlider, Path=Value}"/>

   <!-- The ellipse will take up any leftover real estate,
                 due to the DockPanel's "auto-fill" behavior -->
   <Ellipse Fill="Green" />

</DockPanel>

When the slider bar is positioned by the user to select its minimum value, the rectangle is given only 10 units of width:

When the user moves the slider bar towards the right, the rectangle's width is given larger values, up to the slider's declared maximum. This dynamic is performed by the data-binding specification, not by procedural code.

Figure 11. Example of one-way data binding

Two-way binding

Now consider an input form allowing editing of an existing database record. Here we use two-way binding—each field in the database record (e.g. zip-code field) would be mapped to the UI control (e.g. text box) representing that field. The two-way binding implements both:

• The initialization of the UI control so it shows the value that was retrieved from the database
• The update of the data when the user interacts with the UI control showing an intent to change the value

Populating UI's via bindings

Bindings are not limited to the case of mapping one UI control to one object's property. The datasource of a binding can also be a collection of data—e.g. the rows being returned from a database query. In this case, the "UI" side of the conduit might be a listbox control, which would be automatically "populated" with the items returned from the query.

Converters

Of course, declarative data binding cannot perform arbitrary logic and data processing; some types of connectivity between UI and the data store will require use of procedural code. Many common cases are automatically handled—e.g. if a textbox is connected to an integer-typed property, string-to-integer data conversion is automatically performed. But, to handle more complex application-specific translation, the architecture allows programmers to create converter functions using procedural code, to which designers can refer when declaring data-binding connections in the XAML.

3.4 Web-Based Applications

The Click-Once installation model

The WPF solution for Web-based automatic application installation builds on the experiences and technology of Microsoft's well-established "Click-Once" installation model.

This .NET technology—often used for the distribution of Windows Forms applications—allows publishers to post an application on a website, which end users can launch via the simple act of clicking on a webpage link or navigating to an URL. That "one click" sets in motion a sequence of events:

• Determination of whether the application needs to be downloaded: (Is it already on the client machine? If so, is it the latest version?)
• If necessary, downloading of the application in the form of a bundle with manifests for verification
• If necessary, automatic execution of the installation, including registration of start-menu items
• Launching of the application (which, in the Windows Forms case, launches a separate window atop the browser window).

WPF applications can be distributed using this same Click-Once paradigm, with a significant advantage being that WPF applications can be hosted in the browser window directly.

"Web Browser Applications"

Even considering the full automation of the Click-Once installation paradigm, it still may nevertheless be considered too "heavyweight" for some cases because the application remains installed "permanently". The user must explicitly remove it subsequently.

Thus, WPF offers a new installation model called Web Browser Applications, abbreviated "WBA". This model is based on Click-Once internally, but varies in this way:

• The installation does not touch the user's start menu or create any "shortcuts".
• When the user closes the browser window running the application, the WBA is marked as being ready for garbage collection, and may indeed be automatically uninstalled at some point in the near future.

The end result: from the user's point of view, no installation occurred, but rather an application was "ephemerally" loaded into the user's browser in much the same way an HTML page is loaded. In a sense, it feels as though the user simply "visited" the application.

4. Preparing for the Windows Presentation Foundation

4.1 Planning an Evaluation Process

Even if your organization is not contemplating immediate adoption of the WPF development platform, it would benefit you to do some evaluation in the short term so you become familiar with the technology, and provide feedback to Microsoft to ensure WPF is where you need it to be when you do start a development effort. WPF will evolve with each release, and the feedback from developers is an important part of ensuring that it provides more value with each release.

In the short term, we recommend that any organization that includes WPF in its 5-year plan allocate a small amount of resources to tasks like these:

• Software Engineers: learn about managed code, or start porting to it if you are ready to do so. You might consider moving the UI to Windows Forms in the short term, which is a good staging ground for WPF adoption.
• Architects and Software Engineers: Evaluate the WPF by reading documentation; installing the runtime, SDK, and VisualStudio "Whidbey"; building sample projects shipped with the SDK; getting familiar with XAML. Send Microsoft feedback if you have concerns about coverage, performance, development efficiency, stability, etc.

In the medium term, we recommend these tasks:

• Marketing, Product Planning: Determine how you can use the WPF to raise your application to its next level and improve its market share, or to unlock new markets. Be creative—WPF is not just about making your interfaces prettier. It can facilitate functionality that previously would have been prohibitively expensive to construct, such as richer web-based experiences.
• Software Engineers: port your systems to managed code, and improve application appearance via some of the techniques described in section 2. There are plenty of improvements you can make with the features with learning curves at the "Lower" or "Medium" level.

It is worth keeping in mind that XAML will likely enable a new development process, where graphics designers and software will collaborate in a direct manner and avail themselves of multiple tools along the way, selecting the best tool for the specific task at hand. As a first step to participate in this new ecosystem, you can extend your existing content-creation tools to save content as XAML, even if you are not ready to build any WPF-based applications.

The bottom line: don't put off an evaluation of WPF just because active work with it lies beyond your immediate horizon. By doing some evaluation and planning activities now, you will—well before you move development processes to it—know what product directions it will facilitate, what new markets or verticals it will allow your organization to play in, and how it will impact your development processes. Sooner or later, your application development on Windows will involve the use of the Windows Presentation Foundation.

4.2 Resources for Learning About WPF

Microsoft's Resources:

• WinFX SDK online: http://winfx.msdn.microsoft.com/library
  Includes a "Getting Started with Avalon" section
• Download of the beta WPF runnable on Windows XP:
  Visit https://msdn.microsoft.com/windowsvista/getthebeta/default.aspx
  and click "Download the WinFX Runtime Components Beta 1."

Books:

• Watch for announcements from Microsoft Press and O'Reilly.

Developer-community resources (mostly not affiliated with or endorsed by Microsoft):

• Newsgroup: microsoft.public.windows.developer.winfx.avalon
• www.xamlshare.com, where developers can share XAML examples and custom controls
• www.longhornblogs.com, where developers and users talk about Vista, XAML, and the WPF
• www.designerslove.net, a Web site focused on graphics designers and WPF