Graphical Composition in Avalonby Ian Griffiths, coauthor of Mastering Visual Studio .NET, and .NET Windows Forms In A Nutshell
Longhorn introduces significant new graphics technology, currently known by its codename, "Avalon." Avalon renders an application's visual elements onto the screen using a much more sophisticated approach than Windows has previously used. In this article, I show how this new graphical composition model solves various limitations of Win32, what new user interface design techniques this enables, and what it means to developers.
Note: the content of this article applies to the Longhorn Developer Preview (build 4051) released at the 2003 PDC. Although this release does not contain the DCE (Desktop Composition Engine), all of the composition techniques described in this article can still be used. The absence of the DCE simply means that Avalon's graphical composition support can currently only be used inside of an application's windows.
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. To see why, we'll take a quick look at where current versions of Windows fall short.
Basic Composition in Windows
Windows has always used a fairly simple form of composition. The screen is divided up into regions, one
for each visible window. (Note that in Win32, controls such as buttons and textboxes are all treated as windows. So
for the purposes of this discussion, a window is anything with an
part of the screen needs to be updated, Windows sends a message (
WM_PAINT) to each of the
windows whose regions are in the area to be redrawn. The programs that own these windows process this message
by using Win32's drawing APIs to construct the appearance of the window on screen. Windows clips this drawing
output so that each window only draws into its allocated region.
The shapes of these regions change dynamically as you move or resize windows. Although programmers can define a region for a window in order to control its shape, the visible region may not be the same as the region specified by the programmer. For example, if any part of the window is obscured by some other window, the effective region will be whatever remains visible.
Figure 1. Two overlapping windows
For example, consider the main client areas of the two windows in the picture above. These areas are both nominally rectangular, but only Window 2's contents currently occupy a rectangular region on screen. The grey client area of Window 1 is partially obscured, so for composition purposes, its visible region is a rotated L shape. (And because Windows XP has added a title bar with curved corners, the L-shaped region Window 1 gets to draw into has a curved inner corner.) Behind that, you can see part of the desktop, and while the desktop window is notionally rectangular, it has quite a convoluted visible region here.
A crucial feature of this style of composition is that none of the visible regions overlap. The notional regions may coincide -- the two windows above clearly appear to overlap. But for composition purposes, only the visible regions count, and visible regions are always disjoint.
Pseudo-Transparency in Windows XP and Windows Forms
The Visual Styles feature in Windows XP and Windows Forms are both able to give the impression of supporting more advanced composition. They each allow a form of transparency, where a parent window's background is visible through a child window. For example, this picture shows a window with a gradient fill background and three child radio-button windows:
Figure 2. A window with pseudo-transparent child controls
The top control works in the old-fashioned way -- it occupies its own rectangle entirely. It has attempted to blend in with its surroundings by filling in its region with what it thinks is the parent window's background color, but it has failed because the parent window doesn't have one single background color. This illustrates one of the shortcomings of a composition approach where any given region of the screen is filled by just one control. However, the other two controls appear to work just fine. Not only does the background show through, but the controls have successfully drawn the text using ClearType rendering, which requires pixel-level blending effects. (And you can even write custom controls that use GDI+ partial transparency to draw see-through things over the form background.)
However, the way this is done is a bit of a hack -- these controls are not really being composed in the way that it appears. They are occupying rectangular regions, just like the control at the top. Visual Styles and Windows Forms both use the same basic trick: "transparent" controls arrange for the parent window to draw their backgrounds for them, passing in their own graphical context. This means that these controls' backgrounds look like that part of the main window would have looked if the child controls had not been there, providing the illusion that we can see the main window behind the controls. However, if any of the child windows overlap each other, it becomes clear that each control still occupies its own region of the screen exclusively, and the illusion is destroyed:
Figure 3. The shortcomings of pseudo-transparency
If you are familiar with the window styles available in Win32, you might be wondering why pseudo-transparency is
done this way rather than by using the
styles. These allow the visible regions of windows to overlap, which sounds like precisely what we want. However,
these flags make it impossible for an application to update its display without flickering. The key to eliminating
flicker is to perform updates in a single step (typically by doing all the drawing into an off-screen buffer, and then
copying that to the screen once all drawing is complete). But these window styles force the painting to be done in
separate stages -- in order to update an area of the screen where multiple controls overlap, Windows must send
WM_PAINT message to each control in turn, which precludes the use of flicker elimination techniques.
By faking transparency the way that they do, the Visual Styles system and Windows Forms permit child windows to
appear to be transparent and yet provide perfectly flicker-free updates.
(Windows 2000 introduced "layered" windows, which really can overlap, and they even support semi-transparent blending. However, this can only be applied to top-level windows. This facility is of no use for composition of child windows.)
Pseudo-transparency works pretty well, in many cases. But it does impose constraints on what kinds of user interfaces you can build. For example, developers who are new to Windows often ask how to use controls to layer adornments, such as selection outlines or draggable items, on top of the contents of a form. Attempting to use pseudo-transparency in these scenarios usually results in overlaps that destroy the illusion.
The inability to handle overlapping siblings also tends to constrain the visual design of forms. The only way for applications to break free of these constraints is to abandon window-based composition entirely -- if you do all of your own drawing into one big window, you can control the composition process yourself, breaking free of these restrictions. Try looking at some of the more visually capable applications that Microsoft produces with a window examining tool, such as Spy++. Internet Explorer, MSN Messenger, and the task list in Windows XP's Explorer all use one big window, and perform their own composition rather than using child windows. One of the giveaways in MSN Messenger is that the scrollbars don't behave quite like Windows scrollbars. Normally, if you move the mouse pointer far enough away from a scrollbar while scrolling, it snaps back to its starting position. But the MSN Messenger scrollbars don't support this behavior. This kind of inconsistency invariably creeps in when applications try to recreate standard components from scratch.
While these applications illustrate that it is possible to break free of the constraints by performing your own UI composition, developers shouldn't have to spend their time doing this. Composition is one of the basic facilities that should be provided by the platform, and if a platform feature no longer meets developers' needs, it's time for the platform to improve. Enter Avalon.
Pages: 1, 2