CLI200: Avalon Overview

CLI200: Avalon Overview

  • Comments 1

Avalon is a separate graphics stack that runs parallel to the existing subsystem all the way up from GDI+. It can be accessed at any level using .NET managed interfaces. Gone are the days of sealed WinForms classes that wrap Win32 controls - this is the starting point for developers to extend and customise. Suddenly you can interact with the Windows environment directly without having to write interop code for all but the most basic scenarios.

The design goals for Avalon involved unifying web and Windows. From the slide:

  • Seamless deployment, update and administration
  • Flowable layout
  • Progressive download and rendering
  • Declarative model
  • Unrestricted functionality
  • Integration with Windows desktop
  • Good offline support
  • Scalability / performance
  • Broad developer language and tools support

Central to Avalon is XAML: Extensible Application Markup Language. XAML is an XML schema for building rich Windows forms applications.

There's a one-to-one correspondence between classes and XAML (extensible application markup). Markup can contain code (or can be loaded like a resource), it can be compiled for execution (either into BAML: a binary pre-processed equivalent, or MSIL). It therefore performs at a comparable speed to MSIL.

One of the underlying dynamics behind XAML is that the role of designers is becoming ever more important; separating the presentation so clearly from procedural code allows for role specialisation. No longer need UI designers produce prototypes that developers implement: they can produce the XAML themselves - indeed Adobe demonstrated a version of AfterEffects (their video editing software) that can be used to generate XAML.

One thing that distinguishes Avalon is support for different layout panels. The most basic examples are absolute positioning and vertical flow layout, but there are many others built into the environment (such as horizontal flow) and you can create your own (perhaps a hierarchical flow layout, for instance). This allows you to produce applications that resemble web pages, Windows forms, or some combination of both or even neither.

Avalon is designed to support future technologies such as HighDPI, 16:9 and sCRGB. Windows are automatically composited to a background buffer, to which effects such as shading and alpha blends can be applied. The co-ordinate system operates using virtual pixels, as if every display was 96dpi. Applications can then be automatically scaled to match the actual dpi. Everything goes through the Direct3D pipeline. Avalon also provides built-in support for new technologies such as Tablet PC and Windows Media Center Edition.

The ASP.NET-esque concepts of repeaters and item templates are brought forward into Avalon. Data can be transformed at the same time as it is bound, and those transformations are two-way.

For document-based applications, Avalon supports automated platform services to enable documents to adapt their presentation for the output device. For example, you can present a document in a fixed format or an adaptive format (a little like the Reading layout capability in Office 2003). Documents can contain rights-management information to limit their distribution too.

Avalon allows you to create design surfaces with little effort - with the addition of a single XAML element, your application can allow its users to move controls around the screen. This is like the difference between the design and run-time views in Visual Studio - both are now supported by Avalon natively, where only run-time capabilities were natively supported in Win32. This feature should be a major boon to reporting applications and the like.

Lastly, the aim is to encourage applications to fit more seamlessly within the shell. By extending the default schema, you can expose meta-data to other applications or the shell itself. New controls (such as Basket), and views (such as Carousel) can be utilised within to increase the interaction between applications.

So how can existing applications prepare for Avalon? The most basic step is to ensure that applications are written using .NET managed code, because existing WinForms code can integrate Avalon controls natively. Separating logic from visuals in applications is also a good step, because then the presentation aspects can be easily replaced if you want to produce something explicitly for Longhorn.

  • A question I'm often asked is, "what's different about WPF in Windows Vista compared to the version that

Page 1 of 1 (1 items)