CLI200: Avalon Overview

  • Article

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.