WPF- Pick Your API Abstraction

Hardware versus Software Rendering

There are some situations which will cause WPF to fallback to software rendering (this is more common in pre-Dx9 video cards or when performing some operations). When this happens, the CPU gets to do more work and likely the overall performance of your application goes down. In many cases, this takes place inadvertedly, thus the need for the Perforator tool, to help track down the cause of falling back to software. There is also a programmatic way of determining whether one is rendering with hardware or software, through the tiering API. Perforator is a bit handier, because it is interactive (for example, you can modify some XAML in XAMLPad and see how it affects hardware acceleration through Perforator). However, you should still use the tiering APIs to adapt the content that your application presents, so that it can work equally well on lower end machines running Windows XP, in software mode.

Factored Access to WPF

It is clear from the questions/discussion in newsgroups that some folks are solely after fast graphics rendering, and perhaps not that interested in the high level/framework services that WPF exposes. Yet, when they use WPF, they feel that they are not getting all the graphics performance they want. We think of WPF as having two major parts, the MIL (Media Integration Layer) and the Framework. The majority of developers will program at the Framework level, and so this is where we focused the development of the SDK first. Some developers do not need the Framework services (Layout, Input, Focus, Eventing – as well as styling, databinding, and XAML). They just want the graphics. For those folks, we provide the Visual layer.

A Diagram of API and Extensibility Points

Hopefully the diagram below will bring to light the different API entry points, as well as the extensibility points, both in WPF and on the technologies we build on.

At the top if the Framework. This is the most common programming abstraction and it is what provides controls (Button, Menu, etc), as well as Layout (Canvas, Grid, etc), and the ability to extend those. It also includes services such as databinding and styling. We use our public APIs to build our own components. This validates the architecture and implementation we built. This means that anyone can develop layouts and controls that are able to match the performance and functionality of the built-in elements (unlike for example in the HTML world, where there are not enough programming abstraction exposed, for example, to build the Table element and perform other layout operations).

At roughly the same level of abstraction as the Framework is XAML-Presentation. We expect that many tools will generate/consume XAML-P, even if not all of those applications are not built using WPF (we have examples of third party and Microsoft applications that fall in this category today already).

Below that, we have the MIL. It presents an API called Visual, which allows developers to do rendering, without a lot of the services available at the Framework level (lower policy, therefore with higher performance in some cases, as there is no layout involved or property system). This marks the transition from managed to native code.

The last API layer below Visual is WPF Imaging Components (WIC), which enables native code applications also to leverage the imaging functionality in WPF (this functionality is exposed at the Framework level as well).



Now we are below the API layer, and into base extensibility points for providing support for new formats, for example. We will begin with WIC Compressors/Decompressors (CODEC), which enable anyone to extend the supported imaging formats on the machine (on Windows Vista, the end user benefits directly from new CODECs in their desktop experience). Next are Effects, which enables developers to add their custom image based effects (Geometry based effects will have to wait until a future version of WPF).

There are also extensibility points in the technologies that WPF uses, which get exposed or used by WPF applications indirectly. The more interesting type are DirectShow filters. This enables developers using WPF’s media element to effortlessly playback different media types (similar to WIC’s CODEC, which provide seamless support for new imaging formats). Hardware folks can provide support for their custom hardware through Direct3D drivers (Windows Display Driver Model in the Windows Vista case) and Print drivers (XP print driver model or Next Generation Print Path drivers – these last type uses XPS as its spool format).

update 05/23/07 - Here is an interesting posting of using WIC for getting DShow content into your WPF application Jeremiah Morrill's blog entry.