Within a top-level window, you can conceptualize that each HWND that comprises one of the technologies of an interoperation application has its own "airspace". Each pixel within the window belongs to exactly one HWND, which constitutes the airspace of that HWND. (Strictly speaking, there is more than one WPF airspace if there is more than one WPF HWND, but for purposes of explaining the concept, presume that there is only one in the examples given in this topic). The airspace concept implies that all layers or other windows that attempt to render above that pixel during application lifetime must be part of the same render-level technology. Attempting to render WPF pixels over Win32 leads to undesirable results, and is disallowed as much as possible through the interoperation APIs.

Airspace by Example

The first example illustrates an application that mixes Win32, DirectX, and WPF. Each technology uses its own separate, non-overlapping set of pixels, and there are no airspace issues.

But suppose you start from that application and create an animation that is controlled by the mouse pointer position and can thus attempt to render over any of these three regions. This would eventually violate airspace. No matter which technology was responsible for the animation itself, that technology would violate airspace of the two others. This is illustrated in the following picture, where the green circle is attempting to move around the window:

Another violation of airspace is if you try to use transparency/alpha blending between different technologies. In the picture below, the WPF box is violating Win32 and DirectX airspace. Because pixels in that WPF box are semi-transparent, they would have to be owned jointly by both DirectX and WPF, which is not possible. So this is another violation of airspace and cannot be built:

The previous three examples used rectangular regions, but the airspace is not necessarily rectangular. It can be a rectangle with a hole (for example, the Win32 airspace here is everything except the WPF and DirectX airspace):

Airspaces can also be completely nonrectangular, or any shape describable by a Win32 HRGN (region):

The window manager process (in both Windows Vista and Microsoft Windows XP) only really processes Win32 HWNDs, therefore every WPF Window is an HWND. The Window HWND must abide by the general rules for any HWND. Within that HWND, WPF code can do whatever the overall WPF APIs support. But for interactions with other HWNDs on the desktop, WPF must abide by Win32 processing and rendering rules. WPF supports non-rectangular windows by using Win32 APIs—HRGNs for non-rectangular windows, and layered windows for a per-pixel alpha.

Constant alpha and color keys are not supported. Win32 layered window capabilities vary by platform.

Layered windows can make the entire window translucent (semi-transparent) by specifying an alpha value to apply to every pixel in the window. (Win32 in fact supports per-pixel alpha, but this is very difficult to use in practical programs because in this mode you would need to draw any child HWND yourself, including dialogs and dropdowns).

WPF supports HRGNs; however, there are no managed APIs for this functionality. You can use platform invoke and HwndSource to call the relevant Win32 APIs. For more information, see Calling Native Functions from Managed Code

WPF layered windows have different capabilities on different operating systems (this is because WPF uses DirectX to render, and layered windows were primarily designed for GDI rendering, not DirectX rendering):

• WPF supports hardware accelerated layered windows on Windows Vista. Hardware accelerated layered windows on Microsoft Windows XP require support from Microsoft DirectX, so the capabilities will depend on the version of Microsoft DirectX on that machine.

• WPF does not support transparency color keys, because WPF cannot guarantee to render the exact color you requested, particularly when rendering is hardware-accelerated.

• If running on Microsoft Windows XP, layered windows on top of DirectX surfaces flicker when the DirectX application renders. (The actual rendering sequence is that Microsoft Windows Graphics Device Interface (GDI) hides the layered window, then DirectX draws, and then Microsoft Windows Graphics Device Interface (GDI) puts the layered window back). Non-WPF layered windows also have this limitation.

Tasks

Concepts