WPF Architectural Article

The Windows SDK Beta 2 refresh is scheduled to happen very soon. At that point in time, the content that we've been working on since the last CTP SDK refresh will become available both in the offline Windows SDK and the http://windowssdk.msdn.microsoft.com site. We'll have an announcement posted as soon as the updated SDK bits are ready.

To whet your appetite for content, here are some passages from a new architectural topic written by Chris Anderson. The full version will appear in the Beta 2 release of the SDK.


One of the primary architectural philosophies we used in building WPF was a preference for properties over methods or events. The basic idea is that properties are declarative and allow you to more easily specify intent instead of action. We also wanted to create a model driven, or data driven, system for displaying user interface content. This philosophy had the intended affect of the creation of more properties that you could data bind to, in order to better control the behavior of an application.

In order to have more of the system driven by properties we needed them to be much richer than typical CLR properties. A simple example of this richness would be change notification. In order to enable two way binding, you need both sides of the bind to support change notification. In order to have behavior tied to property values, you need to be notified when the property value changes. In .NET today there is an interface, INotifyPropertyChange, that allows an object to publish change notifications, however it is optional.

WPF provides a richer property system, derived from the DependencyObject type. The property system is really a "dependency" property system in that it tracks dependencies between property expressions and automatically revalidates property values when dependencies change. For example, if you have a property that inherits (like FontSize), the system is automatically updated if the property changes on a parent of an element that is inheriting the value.

The foundation of the WPF property system is the concept of a property expression. In this first release of WPF, the property expression system is closed, and the expressions are all provided as part of the framework. The notion of expressions is why the property system doesn’t have data binding, styling, or inheritance hard coded, but rather provided by the later layers of the framework.

The property system also provides for sparse storage of property values. Because we expected objects to have dozens (if not hundreds) of properties, and we expected most of the values to be in their default state (inherited, set by styles, etc.), we didn’t want to have every instance of an object have the full weight of every property.

The final key feature of the property system is the notion of attached properties. WPF elements are built on the principle of composition and component reuse. It is often the case that some containing element (like a Grid layout panel) needs additional data on child elements to control its behavior (like the Row/Column information). Instead of associating all of these properties with every element, we instead allow any object to provide property definitions for any other object. This is similar to the "expando" features of JavaScript.


With a system defined, the next step is to actually get some pixels drawn to the screen. Visual provides for building a tree of visual objects, with each optionally containing drawing instructions and metadata about how to render those instructions (clipping, transformation, etc.). Visual is designed to be extremely lightweight and flexible, so most of the features have no public API exposure and rely heavily on protected callback functions.

Visual is really the entry point to the WPF composition system. I mentioned before about milcore, and how it is an unmanaged component that we talk to from our managed API. Visual is the point of connection between these two sub-systems.

WPF displays data by traversing the unmanaged data structures managed by the milcore. These structures, called composition nodes, represent a hierarchical display tree with rendering instructions at each node. This tree, illustrated on the right hand side of the figure below, is only accessible through a messaging protocol.

When programming WPF you create Visual elements, and derived types, which internally communicate to the composition tree through this messaging protocol. Each Visual in WPF may create one, none, or several composition nodes.

There is a very important architectural detail to notice here – the entire tree of visuals and drawing instructions is cached. In graphics terms, WPF uses a retained rendering system. This enables the system to repaint at high refresh rates without the composition system blocking on callbacks to user code. This helps prevent the appearance of a hung application that you see in many programs.

Another important detail that isn’t really noticeable in the diagram is how the system actually performs the composition.

In User32 and GDI, the system worked on an immediate mode clipping system. When a component needed to be rendered, the system would establish a clipping bounds outside of which the component wasn’t allowed to touch the pixels, and then the component was asked to paint pixels in that box. This system works very well in memory constrained systems because when something changes you only have to touch the affected component – no two components ever contribute to the color of a single pixel.

We’ve already talked about WPF using a retained model for rendering, but it also does uses a "painters algorithm" painting model. This means that instead of clipping each component, each component is asked to render from the back to the front of the display. This allows each component to paint over the previous components display. The advantage of this model is that you can have complex partially transparent shapes. With today’s modern graphics hardware, this model is relatively fast (which wasn’t the case when User32/).

As mentioned previously, a core philosophy of WPF was to move to a more declarative, "property centric" model for programming. In the visual system this shows up in a couple interesting places.

First, if you think about the retained mode graphic system, this is really moving away from an imperative DrawLine/DrawLine type model, to a data oriented model – new Line()/new Line(). This move to data driven rendering allows complex operations on the drawing instructions to be expressed using properties. The types deriving from Drawing are effectively the object model for rendering.

Second, if you look at the animation system, it is completely declarative. Instead of requiring a developer to compute the next location, or next color, you can express animations as a set of properties on an animation object. These animations can then express the intent of the developer or designer (move this button from here to there in 5 seconds), and the system can determine the most efficient way to accomplish that.

About Us

We are the Windows Presentation Foundation SDK writers and editors.

Skip to main content