Airspace Now that we understand what's going on behind the scenes, let's describe some of implications, which I refer to as "airspace". Within a top-level window, I like to think of each hwnd as having its own "airspace" -- each pixel within the window belongs to exactly one hwnd, which constitutes that hwnd's airspace. And informally, I'll talk about the Avalon airspace versus the DirectX airspace versus the Win32 airspace -- although strictly speaking, there will be more than one Avalon airspace if there's more than one Avalon hwnd. I call it airspace because like air traffic control, bad things happen when you try to travel into someone else's airspace.
Let's walk through a couple examples. We'll start with an application that mixes Win32, DirectX, and Avalon, since each technology gets its own separate, non-overlapping set of pixels, everyone is happy:
But suppose you take that same application, and create an animation that flies over those three regions, that violates airspace. Which technology is drawing that animation? No matter what the answer, that technology will violates someone else's airspace, so it can't be built. This is illustrated in the below picture, where the green circle is attempting to move around the window:
Another violation of airspace is when we use transparency/alpha blending between different technologies. In the picture below, the Avalon box is violating Win32 and DirectX airspace -- because pixels are semi-transparent, they would have to be owned jointly by both DirectX and Avalon, which is not possible. So this is another violation of airspace and can't be built:
Previous three examples used rectangular regions, but there's no reason that airspace has to be rectangular. It can be a rectangle with a hole (e.g., Win32's airspace is everything except the Avalon & DirectX airspace):
And airspaces can be completely nonrectangular, indeed any shape describable by a Win32 HRGN (region):
Hwnds inside AvalonHwndHost lets you put hwnds inside Avalon – think of HwndHost as a special control (technically, FrameworkElement) that hides the hwnd-ness from the rest of Avalon. HwndHost mostly behaves like any other Avalon FrameworkElement, although there are some important differences around output (drawing and graphics) and input (mouse and keyboard) stemming from limitations in what hwnds can do.
Differences in output behavior include:
Differences in input behavior include: