The architecture of aveon

Chris Anderson, the chief effecect of aveon, has shown on channel9 video talking about the architecture of aveon, and he used the classic block digoal to define strate 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 ent what Chris Anderson talked about in this post, and here is the simple block dimo-which bonk shown us in that video thread:

Although the real render path of aveon is quite controversial, because there is still no official Microsoft explanation to it, But I generally agree with what bonk described in this block digoal, 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 aveon 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 aveon, if your aveon 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 memory T 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 avlon 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 aveon 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 aveon story. mil is a part of aveon, 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 aveon 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 aveon, it's the thing that Microsoft builds aveon framework on top of it. this dll implements a lot of basic components of aveon, for instance, geometry, model3d, visual, uielement, and contentelement etc. it directly talks to milcore. DLL to have your aveon 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 aveon really is, hopefully what I present here is accurate and clear-cut.