Loading User Information from Channel 9
Something went wrong getting user information from Channel 9
Loading User Information from MSDN
Something went wrong getting user information from MSDN
Loading Visual Studio Achievements
Something went wrong getting the Visual Studio Achievements
JBeda
Avatar stolen directly from messenger
| Forum | Thread | Replies | Latest activity |
|---|---|---|---|
| Coffeehouse | There goes another one | 12 | Sep 09, 2004 at 1:10 AM |
| Coffeehouse | Show me your favorites Scoble! | 8 | Apr 07, 2004 at 5:22 PM |
| Coffeehouse | Where are the Microsofties? | 15 | Apr 07, 2004 at 2:12 PM |
Here is a list of Channel 9 staff members.
© 2013 Microsoft. Except where designated as licensed by
Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 License,
Microsoft reserves all rights associated with the materials on this site.
Jim Allchin - The Longhorn Update
Aug 30, 2004 at 9:16 AMActually, 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.
Joe Beda - Is Avalon a way to take over the Web?
Aug 21, 2004 at 5:08 PMHa -- 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.
Joe Beda - What hardware will Longhorn/Avalon need?
May 17, 2004 at 4:53 PMThe 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.
Joe Beda - What hardware will Longhorn/Avalon need?
May 15, 2004 at 10:37 AMEven 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
Joe Beda - Managed vs. unmanaged, how much of Avalon was done that way?
Apr 12, 2004 at 9:21 AMI 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".
Joe Beda - What hardware will Longhorn/Avalon need?
Apr 10, 2004 at 10:30 PMAfter 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!
What 3D capabilities will Longhorn/Avalon provide?
Apr 10, 2004 at 10:27 PMJoe Beda - Is all of Avalon managed?
Apr 10, 2004 at 11:28 AMI 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
Joe Beda - How should developers prepare for Longhorn/Avalon?
Apr 10, 2004 at 11:24 AMI'm glad to hear this! These are exactly the scenarios that we are working hard to hit with Avalon and Longhorn in general.
Joe Beda - Is Avalon a way to take over the Web?
Apr 10, 2004 at 11:22 AMI 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.
See more comments…