Friday, February 10, 2006

“Avalon”
Avalon is the code-name for the presentation subsystem in "Longhorn." Avalon provides the foundation for building applications and high fidelity experiences in Longhorn, blending together application UI, documents, and media content, while exploiting the full power of your computer. The functionality extends to the support for Tablet and other forms of input, a more modern imaging and printing pipeline, accessibility and UI automation infrastructure, data-driven UI and visualization, as well as the integration points for weaving the application experience into the Windows shell.
Composition of Visual Elements
In computer graphics, composition is the process of combining multiple images into a single image. It can mean anything from the very simple process of showing two pictures next to each other right up to the sophisticated techniques used in the cinema industry, where each frame may be made up of hundreds of images combined using a wide range of visual effects.
All windowing systems support some level of composition. The image you see on your computer screen is composed from many discrete elements. For example, a web browser window typically has many toolbar buttons, an address field, a menu, and a status bar, as well as the main browsing panel. These elements are combined with the window title bar and borders supplied by the OS to form the appearance of the whole window. This in turn will be the composed with any other windows that are currently visible to form the image on your screen. The set of composition techniques a windowing system offers influences the way in which user interfaces can be built. Avalon offers much more sophisticated graphical composition than has previously been available under Windows.

1) Basic Composition in Windows
2) Pseudo-Transparency in Windows XP and Windows Forms
3) Off-Screen Composition
4) Retaining the UI

The new composition model in Avalon removes many of the visual design constraints that applied to most Win32 applications. It also improves performance by making more effective use of modern graphics cards, reducing the frequency with which the OS has to call the application back to keep the display up to date, and enabling a much higher quality of user interface.


“XAML”
One of Longhorn's most interesting technologies for developers is its new XML-based markup language, codenamed XAML (short for eXtensible Application Markup Language, and pronounced "Zammel"). User interfaces in Longhorn applications are typically built using XAML. In this article, we look at how XAML relates to the underlying support provided by WinFX.
XAML user interfaces are built in much the same way as HTML web user interfaces -- you simply create a document with tags for each of the user interface elements you require. Here is a simple XAML user interface: Hello World
This particular example displays a Text element and a Button element, using a FlowPanel to arrange them on screen. These are all classes defined by Avalon, WinFX's user interface framework. The Text and Button elements are self-explanatory. The FlowPanel is an example of a panel. Panels are used to arrange elements according to a particular layout approach. The FlowPanel arranges elements on screen in the same way that text is typically formatted -- elements "flow" through the available space from left to right, moving onto the next line when no more space is left on the current line. The results are shown below. (The first picture shows a window wide enough to contain both elements on one line. The second shows what happens when the window is not wide enough -- the FlowPanel splits the elements across two lines.) Avalon offers a variety of panel types for different layout techniques, including fixed layout, docking, and column-based text flow.

Why a New Markup Language?
You might be wondering why Microsoft decided to invent a brand-new markup language for building user interfaces, rather than using HTML or SVG. One of the reasons is functionality -- Avalon provides many sophisticated user interface features that are not available in HTML, such as scaling and rotation of both text and graphics, and animation. Also, HTML has been developed primarily for use on the Web, whereas XAML's principal target is applications that run directly on Windows (i.e., "rich clients" or "smart clients"). But this still leaves the question of why Microsoft didn't use SVG (Scalable Vector Graphics -- a graphically rich, XML-based markup language.) After all, SVG addresses many of HTML's shortcomings as a rich-client markup language. However, the most powerful reason for devising a new markup language is the very close relationship between elements in a XAML file, and objects at runtime. Unlike any previous markup languages, XAML is designed to integrate directly with WinFX.
XAML is a simple but powerful way of building trees of .NET objects. Because it is based on XML, it is straightforward to create XAML-based markup. This not only makes it easy to build user interfaces by hand, it also makes it relatively straightforward for tools to generate XAML -- in the future, design tools will emerge that are able to export documents and drawings in XAML format. It is also easy to use technologies such as XSLT to transform XML data sources into XAML documents. XAML enables a clean separation of user interface from code through the use of code-behind files, while its close integration with WinFX makes it very easy for code to manipulate the user interface elements defined in the markup.


“WinFX: An All-Managed API”
In Longhorn, Win32 will no longer be the principal API. It will, of course, continue to be supported; 20-year-old DOS applications still run on the latest version of Windows, and likewise, Win32 applications will also continue to work for the foreseeable future. But just as DOS and 16-bit Windows applications were superseded by Win32 applications, so in Longhorn will Win32 become the "old way" of doing things. In Win32's place is a new API called WinFX (pronounced "Win Effects"). WinFX is a significant milestone in the history of the Windows API, as it puts .NET at the center of the platform. While Win32, the main API for previous versions of Windows, is a C-style API, WinFX is designed primarily to be used by .NET languages. In other words, it is a managed API. Moreover, it is a superset of the existing .NET Framework.
Judging by the discussions on various newsgroups and mailing lists, many seasoned Windows developers seem to have a hard time believing that Longhorn's new APIs really will be pure .NET. The topic has come up almost every day on the various WinFX Microsoft newsgroups since the API's announcement, and it seems that many people think that a .NET-only API cannot possibly exist, and that there must be a 'real' Win32 API underneath it all.
The idea that Win32 must be lurking somewhere beneath the covers presumably originates in part because of the way today's .NET Framework is implemented. Many of the classes in the Framework Class Library are wrappers on top of Win32 functionality. For example, Windows Forms puts a .NET face on classic Win32 features such as HWND, MSG, and WndProc. Likewise, the various classes in System.Net and System.Net.Sockets ultimately wrap the services provided by the Windows Sockets API in Win32.
Pure Managed Functionality
The ability of WinFX to link directly to system services, bypassing Win32, is not the only way in which new Longhorn features can be exposed in WinFX but not Win32. Many features will be implemented entirely in managed code with no need for any help from lower levels of the platform at all.
There are already many examples of pure managed features in the shipping versions of .NET Framework. For example, you can make extensive use of the XML functionality in the current versions of .NET without the framework ever making a call into Win32. Likewise, although ASP.NET integrates with IIS in the Win32 world, the vast majority of the value that it adds over the unmanaged ISAPI extension mechanism is implemented in managed code. The ASP.NET page caching mechanism has no Win32 equivalent; neither do the key parts of its object model. (HttpRequest, HttpResponse, and friends may look reminiscent of the classic ASP objects, but they are not wrappers. They were designed to look very similar to the ASP object, in order to ease the transition to ASP.NET, but they are all implemented entirely in managed code.)
The same will be true for much of the new functionality in Longhorn. There will, of course, be some things which involve new platform features all the way from WinFX's public API right down to kernel mode-- the new 'Avalon' graphics model being the most obvious example. However, there will be many more features implemented entirely in managed code. For example, although Avalon relies on platform support at all levels for performance reasons; a considerable amount of its functionality will reside entirely in managed code. (It would be rather inefficient if every single interaction your code had with Avalon objects caused calls all the way down into the lowest levels of the OS.)

1 Comments:

At 4:35 AM, Blogger Scott A. Edwards said...

The fact is that the INTERNET is making people RICH! Shouldn't YOU be one of them? Click here: FIND OUT NOW!

 

Post a Comment

<< Home