No version of Avalon is built on top of GDI+: It is built on top of DirectX. XP, 2003, or Longhorn… doesn’t matter. As such it leverages all the features of the GPU to do all rendering. This includes 2D as well as 3D. In fact, all 2D is actually accomplished using 3D. GDI[+] is still available even in Longhorn, it’s just that Avalon completely bypasses it. Note that you can host WinForms and pure Win32 controls in an Avalon application and, believe it or not, vice versa.

Avalon != XAML and not a “declaritive markup engine”: This is a common misconception. XAML stands for: Extensible Application Markup Language. It is simply a serialization format that allows you to declaritively define an object graph based on everyone’s favorite syntax: XML. Avalon controls are just one kind of object graph that can be built and, obviously, the most common example right now. However I could just as easily construct a graph of any other type of .NET objects. That said, the XAML serialization engine is part of the Avalon API.

“Loose” XAML no longer browseable as of latest builds: As of the March CTP you can no longer simply browse to a XAML file. It must be compiled into an application. The main reason for this seems to be that Microsoft does not want to promise delivery of this feature because of all the security holes it could potentially open up. There tends to be a lot of discussion about this in the Avalon newsgroup. Also, “browsing to an application” really has nothing to do with XAML or even Avalon, but rather smart client technology, aka Click Once as mentioned. Windows Forms apps can be run exactly the same way.

Avalon backported to XP/2003 because: The plan was not always to backport it. The reason it was backported is so that third parties can develop applications built on this great technology and have them work on XP/2003 as well as Longhorn. Obviously not everyone is gonna run out and upgrade to Longhorn “day zero”. That said, some features of Avalon will only be available on Longhorn, not to mention that the new graphics driver model (the LDDM as mentioned) coupled with the Desktop Window Manager (DWM) that come along with Longhorn ensure a vastly better experience when you have multiple Avalon applications running. This is because the old driver model for GPUs does not lend itself to multi-tasking. The current display driver model was basically meant to run GDI[+] or one 3D application as fast as the metal allowed (e.g. Doom 3 or HalfLife-2 full screen). Now that the GPU is a core dependency of the way the OS displays everything on your desktop, it needs to support richer scheduling as well as virtual memory. For more information on what differences there are between platforms, check out this post from Chris Anderson. For info on all the improvements being made to graphics technology in Longhorn, definitely check out this article that was just published over on ExtremeTech.

Share this:

Leave a comment

Backporting: I wasn’t sure whether it was part of the plan or not (and I said so) because backporting WAS a part of the plan from day one on Indigo.

The rest: I stand corrected. Maybe I shouldn’t do interviews at 2am.

I would note that RE: XAML != Avalon – until people stop explaining it as “XAML lets you create an object graph” people are still going to see it this way. I would argue that few everyday developers know what an object graph is. It would also help to come up with another example of how to do it besides through XAML.

Regarding Point 1, however, isn’t the threading, databinding, eventing, etc stuff a part of WinFX and not Avalon? Doesn’t Avalon use these things as a layer on top of WinFX?

There’s actually a lot more to the backporting story too. Avalon devs were being held back by the unstable core features of the brand new OS. By backporting to XP (SP2 min btw) they were guarenteed a stable base to move forward on. At the same time though, there are some challenges to delivering all the original promises of Avalon on the older OS.

As far as correcting, I just hope you understand I wasn’t trying to bash/discredit you or anything. You definitely seem to have more of a breadth of information about the whole OS, Avalon just happens to be my little niche that I choose to focus on. 😉

I also agree with the XAML != Avalon message. It’s really hard to deliver the right message. XAML is such an important part of Avalon because it’s so core to delivering the message of separation between presentation and logic… developers and designers.

Finally, point one… it’s also a tough call because there hasn’t been a clear message as to what pieces fall under what technology. WinFX is a bigger umbrella that encompasses Avalon, Indigo and a bunch of other API advancements. Since the WinFx SDK explicitly refers to these things as ‘”Avalon” Event Model’ or ‘”Avalon” threading model’ I’ve been assuming they are tied most strongly to Avalon itself.

Were any of you in the Lockergnome IRC channel during the airing of the show?

I was pulling my hair out during parts of it! No offense Robert, but when you said that Avalon rendered through GDI, I almost cried!

Avalon was originally going to render through “DirectX Next” or the “Windows Graphics Foundation” – both fancy names for DirectX 10.

Now it looks like Longhorn might not even ship with DX10, and Avalon is going to render through DirectX 9 on XP/2003/Longhorn – according to what’s been said so far (ie. don’t kill me if it ends up running on DX10 or 9.1 or something).

Brandon… sorry. I was trying to say that GDI will still be in Longhorn, and you could still program against it, but that’s not what ended up coming out. It was trying to explain Longhorn to someone who didn’t know much of anything about it before that week… I was bound to make a few gaffes.