Comments

BOFH wrote:

Since MS have been, officially, very quiet about DCE - even at the WinHEC and PDC events - some people still fail to understand that whilst Avalon is the "presentation layer", it isn't the rendering engine which Explorer Glass is built on. That function still comes down to DCE, which will not be backported to XP.

Actually, I think you got some of the fine points of the Avalon graphics architecture wrong here.  Avalon does include the rendering and compositing engine.  The DWM is being built on parts of the Avalon platofrm.

The main part here to keep in mind is the UCE -- Unitified Composition engine.  This is a evolution from what we were calling the DCE (Desktop Compostion Engine) and the ACE (Application Composition Engine) early on.  We basically looked at the problems we were solving to composite applications on the desktop and we looked at the problems we had to solve to composite controls inside the app and discovered (huge surprise..) that these situations were very similar.  So we merged these two parts together to create one unitified engine.

An instance of the UCE runs as part of every Avalon application (doesn't matter on OS) and does the composition for the client area of that application.  This will allow any app developer to do transparencey and other cool composition effects inside of the window.  The output of this UCE gets passed desktop management system for dispaly.  When the DWM isn't running, this means that the content gets presented by DX or GDI (depending if HW accel is being used).  When the DWM is running this content gets passed to an instance of UCE running inside of the DWM process.

The DWM process has an instance of the UCE that is special in that, when the DWM is running, it is the thing that finally takes the content and puts it on the screen via fulls screen DX.  It is essentially an Avalon application that takes all of the client areas for each application (GDI, DX and Avalon alike) and merges those together into the composited desktop.

The basic architecture won't change with this announcement.  However, the DWM will only be shipped on Longhorn as it is impossible to reasonably retrofit the redirection capabilities necessary to make it work on XP and W2k3.  But *inside* the client area of an application the Avalon architecture remains essentially unchanged.

There are more details in my blog here: http://www.eightypercent.net/Archive/2004/08/30.html#a208.

Joe

After-post mint:  I kept reading and it looks like you guys are way ahead of me and found our WinHEC slides.  Avalon will basically run as it always has inside the window.  The desktop composition stuff will be built on parts of Avalon and will run only on Longhorn.

cliftonm wrote:

Uh, right.  Like his latest barbeque and speeding ticket case.  Yup, I sure am interested in knowing about these very important activities of the Avalon team.

NOT!

Ha -- I guess the Avalon stuff has scrolled off the bottom. 

Here are some links to get you started:
http://www.eightypercent.net/Archive/2004/06/30.html
http://www.eightypercent.net/Archive/2004/06/18.html
http://www.eightypercent.net/Archive/2004/06/21.html
http://www.eightypercent.net/Archive/2004/05/18.html
http://www.eightypercent.net/Archive/2004/05/24.html
http://www.eightypercent.net/Archive/2004/05/12.html
http://www.eightypercent.net/Archive/2004/05/06.html
http://www.eightypercent.net/Archive/2004/04/12.html


It is hard to keep coming up with new topics.  There is a ton of info but I'm not sure what people are interested without repeating myself ad nauseum.  If there is something that interests you then send me an email at "eightypercent AT Bedafamily DOT com" and I'll do my best to answer.

sbc wrote:

Why can't it run on a lower spec one (i.e. 8MB), or even on a 2D one?

...

Or is that only if you wish to use Aero (as the article also says there is a fallback to Win2k UI - which surely should work even on 4MB cards)?

The 32MB DX9 generation card is what is necessary to get a Windows "Longhorn" logo and run with the Aero experience.  However, we will run on hardware that is less capable than that.  Specifically for laptops we will have a way to optimize for battery life.

If we have less than a DX7 card or if we run out of memory we can always fall back to software rendering.  Everything that we render can be done in software also.  This is necessary for things like printing or rendering to a system memory bitmap.

sbc wrote:

Surely Avalon isn't really needed for the server version?

Even though Avalon isn't going to be key to most servers, I think that it is necessary to have a base level of the platform available all the time.  It doesn't have to be pretty and it doesn't have to be super fast, but applications have to work.  I think that there is something to be said for a Windows application runs on Windows whatever the version.

Win2k3 server comes with hardware acceleration turned off by default (to minimize crashes in the video driver).  If we do the same thing moving forward (I have no idea one way or the other) you can bet that we will make sure that applications still run.  All of Avalon graphics has a software fallback.

Beyond that, you can do cool things with AValon that don't stress the hardware and aren't "cool flying stuff".  We are also a new UI toolkit and framework.  Say what you will about cool graphics, but even a server can use good UI on occasion (if you aren't the the type to do everything on the command line).

Also, we want to make the remoting (Remote Desktop and Terminal Services) work super well with Avalon.  In that case the parts of Avalon that do stress the graphics hardware (the composition process and all drawing operations) will happen on the client machine.  This means that Avalon will be running on the server but the heavy graphics lifting can be done by the client.

Joe

daniel wrote:

Are you at liberty to discuss how this has evolved. For example were there considerable portions of managed code that had to be moved over to unmanaged for tweaking purposes ? or unmanaged code that was migrated to managed because it was cleaner to handle and maintain ?

I can speak to this a little bit.  Originally, we didn't know if we were going to have to deliver an unmanaged API to go along with our managed API.  To do this, we implemented our visual (basically a node in our display tree) in unmanaged code with managed wrappers.  We hit real problems with lifetime management when we wanted to attach any sort of managed data to our unmanaged objects.  This happened when we let users attach data to the visuals (think SetWindowPtr) or try to call back into managed code (think WM_PAINT). WinForms handles this type of thing (I think) with hash tables and explicit lifetime management.  Neither of those is efficient enought or clean enough for where we wanted to go with Avalon.

The basic problem is that if you have a well connected object graph, it doesn't work well split across the managed/unmanaged boundary.  The simple way to do this is to have everything that unmanaged code is holding on to be a GC root.  This means that the GC won't see through unmanaged code to collect the managed object held on to by managed code.  To put it in concrete terms, suppose you have a managed object A (Am) that is holding on to an unmanaged object B (Bu).  No suppose that Bu is holding on to a managed object C (Cm).  Now suppose (directly or indirectly) Cm is holding on to Am.  In this situation we have a reference loop that goes through unmanaged code.  Even if there are no external references holding on to any of these objects, the GC will never know to collect them as it can't trace the indirect reference from Am to Cm.

The upshot is that you really want the transition layer to be as "one way" as possible.  APIs like GDI+ (System.Drawing) or DX work well because they rarely call back or hold on to managed user data.  APIs like WinForms (which is, amoung other things, a wrapper on USER) have to bend over backwards to straddle the line like they do.

Internally, we moved a bunch more stuff over to the managed side so that we could make our API be more "one way".

Karim wrote:

Yeah, so what hardware will Longhorn/Avalon need??? [snip]

Also, have you considered "Presentation Manager" as a name for the desktop compositing engine?  Now that you guys are working with IBM again, I think it's fair game.  LOL

After WinHEC, I'll feel more comfortable speaking publically about our required and recommended hardware.  I'll point this thread to our main PM in that area and maybe she'll be fine with talking to this early.

As for Presentation Manager -- I hadn't heard that yet.  That name hasn't come up in our discussions but it would be pretty funny!

Supporting HLSL would be super cool.  We are still figuring out the way to meld that with a general 2D API.  We have a bunch of ideas, but it is still unclear how much we can get done in v1 and what the security and scalability implications are.

Charles wrote:

Another way to put this, should I be so bold, is that the need to be unmanaged when writing a next generation Windows application will become the exceptional notion, not the expected behavioral pattern, in Longhorn.

I think that is a great way of putting it.  Of course developers are still going to be able to write software using Win32 (and Win16 and assembly, but we really think that managed code is the next level and we are working to make sure that Windows has a consistent and very capable API in managed code.  The name for that effort (and we started using it at the PDC) is WinFX.  The implication here is that WinFX is the next thing after Win32.

Lwatson wrote:

About power on the desktop and net aware rich applications, I am extremely excited over the prospects that this paradigm brings to the table for application development.

I'm glad to hear this!  These are exactly the scenarios that we are working hard to hit with Avalon and Longhorn in general.

SuperRob wrote:

I think that there are ways to do both, I'm just wondering how much more research Microsoft is doing with it.

I do know that MSResearch is looking in to this quite a bit.  I don't know how much of that will make it in to the product in the longhorn timeframe.  However, with the desktop compositor, we will have the capability to explore some of these ideas better than we have ever been able to before.

Check out the Task Gallery example of something done ~4 years ago from MS Research.  Some of the same people have done some interesting things since, but I can't find it on the MSR site right now.