Chris Anderson, the chief architect of Avalon, has shown on Channel9 Video talking about the architecture of Avalon, and he used the classic block diagram to illustrate how the UI is rendered from the top layer down the road to the GPU.Unfortunately I am a late catcher of this video, but I will try to present what Chris Anderson talked about in this post, and here is the simple block diagram which bonk shown us in that video thread:

Although the real render path of Avalon is quite controversial, because there is still no official Microsoft explanation to it,but I generally agree with what bonk described in this block diagram, and I try to explain how the different piece of layers/ components work together to make the magic happen.
    Computer Monitor: it's no brainer that this one is for physical display of the final graphics:-)
    Driver layer(XPDDM or LDDM): this layer is heavily bound to specific GPU specification, XPDDM stands for Windows XP Display Driver Model and LDDM for Longhorn Display Driver Model, because the Avalon currently can run on three Microsoft operating systems,aka Windows XP, Windows Server 2003, and Windows Vista(formerly codenamed Longhorn), so there are two driver models for Avalon, if your Avalon application runs on Windows XP or Windows Server 2003, the XPDDM will be used to interact with GPU, if your application runs on Windows Vista, the superior and performant LDDM will be used. I guess what this layer actually does is to send the instruction set which is generated by the upper layer to the GPU for final execution.
    User32.dll and Direct3D:user32.dll is a module that contains Windows API functions related the Windows user interface (Window handling, basic UI functions, and so forth). I guess what the User32.dll actually does here is to make it possible for your Avalon application to interact with the underlying Windows operating system, it will set window space for your application, and tunnel any Window message dealing with window activity, keyboard handling, mouse handling etc to your Avalon application. so now you have User32.dll setting window space for your application, then what the Direct3D does here is to render the content inside this window space.
    MIL layer(milcore.dll, WindowsCodecs.dll, presentationcore.dll): up from now, we are actually running into the real Avalon story. MIL is a part of Avalon, it stands for Media Integration Layer, MIL contains three basic building blocks, they are milcore.dll, WindowsCodecs.dll, and PresentationCore.dll). milcore.dll is the unmanaged composition engine that Avalon uses for rendering. milcore.dll as Chris Anderson described in that video is the super secret, confidential component which is ultimately responsible for setting pixels. milcore.dll takes in a bunch of 2D, 3D, text, and imaging content, and translates all those things into something Direct3D can understand, there is another unmanaged component namely WindowsCodecs.dll, which houses all the unmanaged implementation of the imaging codecs - BMP, JPG, etc, and on top of these two unmanaged components, Microsoft builds a simple managed API called PresentationCore.dll, PresentationCore is the low level APIs of Avalon, it's the thing that Microsoft builds Avalon framework on top of it. this dll implements a lot of basic components of Avalon, for instance, Geometry, Model3D, Visual, UIElement, and ContentElement etc. It directly talks to milcore.dll to have your Avalon UI content rendered.
    PresentationFramework.dll: PresentationFramework.dll is built on top of PresentaionCore.dll, it contains a lot of innovative stuff, it consists of seven basic ideas, they are application, controls, styling, layer, data, contents, and actions. this dll is what we are familiar with and program against.
    Okay, this is what the Avalon really is, hopefully what I present here is accurate and clear-cut.