Aero and Sonar (Jose7822 Please Read)

I have been informed that some have found that Sonar will not work as well with Aero on. I have found just the opposite on my setup. Sonar definably runs much better with Aero then with out. Below is from a article that helps explain why it will run better.

"Technical Overview of the DWM
The DWM interface, available on all versions of Windows Vista except Windows Vista Home Basic, is housed in dwm.exe. All applications in the system benefit from the DWM without any modifications or recompilations.However, applications that choose to take advantage of specific DWM features can call to interfaces in dwmapi.dll (the public interface of DWM), which will then pass them along to dwm.exe. The interface declarations are found in dwmapi.h and you can get up-to-date API information online from windowssdk.msdn.microsoft.com.
Windows Vista was designed to use graphics accelerators for every window, not just for 3D DirectX® applications. In order to do this, DWM talks to WDDM, which is the ultimate owner of the graphics processor and video memory. (DWM relies on milcore.dll, a component shared with Windows Presentation Foundation, for output and rendering to DirectX.) Rendering is handled by a separate thread in DWM, inaccessible to the user, that owns the DirectX device. In addition, most applications have their own threads that handle rendering and UI (such as the USER message pump thread in a typical Win32® application), but which don't conflict with DWM's rendering thread. The DWM gets a list of windows and manages their bitmaps in a tree structure, which it then composites onto the final desktop.In other words, each application renders its own bitmaps that are then composited by the DWM.
An application's main window thread renders its scene, the scene is accessed by the DWM render thread, and the render thread updates the desktop through its DirectX interface. The information passed is compacted to just changes (deltas) from the previous render, and large data, like images, are placed in shared memory. This can potentially allow the scene generation to occur on one machine while the final rendering can be done on another machine. 3D programmers who have used OpenGL will be familiar with this architecture, which allows a server to manage a 3D scene and just send deltas to the client machines. You can have a distributed rendering of a 3D scene and have it running with full hardware acceleration on any number of client machines.This architecture allows the DWM to provide first-class support for Remote Desktop scenarios.
While Windows Vista will run with a legacy Windows XP-compatible driver, a WDDM video driver is required to get all the DWM features. Contrary to some speculation, DWM doesn't require DirectX 10, but does require some more video/texture memory and a video card that supports Shader Model 2.0 or better. The biggest change with using WDDM is that it introduces the Video Memory Manager (VidMM), which can swap video memory allocations between system memory and video memory. This means that WDDM can virtualize the video card's resources so that it's possible to do a better job of sharing and swapping video memory, and of context-switching the graphics processor among different threads in disparate applications. It used to be nearly impossible to run multiple 3D applications with any kind of stability, due to drivers that were unable to handle context switches. And prior to WDDM, there was no formal scheduling available, so often one DirectX application would starve others.With WDDM, it's much harder for that to happen. Drivers are also on a much tighter leash for Windows Vista and are forced to be much more robust than for previous versions of Windows.
As an aside, note that DirectX 10 is a Windows Vista-only API. Applications designed for previous version of DirectX will run on a legacy DirectX API implementation expected to be called DirectX 9 L.This will be the last version supported by pre-WDDM drivers. DirectX 9 L apps are expected to run on Windows XP with DirectX 9 L installed as well as on Windows Vista. DirectX 10 contains no legacy interfaces." To read more see this Here.

Also see this a white paper on this Here too


I am thinking that those that may have problems here have graphics that are marginal in their Vista compatibility. I run a dual monitor setup and its the least optimized part of my setup. I run different resolutions on each monitor. Yet I get outstanding graphics response with Aero on and fully activated. I have all the Aero features on.

Any questions will be answered if I have the answers on this.

This thread is for Jose because we had a conversation dealing with this in the sticky thread Color Schemes. I started this in order to see why he is not seeing the same as me. I said I would start a new thread instead of being OT on that one.

space.. it's also a chocolate bar in the UK anyway.

Hey John,

Thanks for openning this thread. As you've said, I don't share your experience with Sonar (under heavy load) when Aero is turned ON. However, I still use Aero because it does look GOOD :-D.

I wonder, for those who report better performance with Aero ON, how are you guys quantifying this? I personally am using the Sonar Benchmark R2 test as well as the DPC Latency Tool. Just curious :-)


Take care!

Jose I just changed the title now I see you are here LOL. OK the way I judge this is with a lot of plugins open and active plus the Console View open. In other words maxing out the amount of screen updates. With XP on the same system it would at some point start to lag. Not a whole lot but start to beg for relief. Closing a window would help. In Vista with Aero I have no such limitation. As for running a benchmark in Sonar I have not done that. It should be consistent with what I see though. If what the Aero desktop is supposed to be doing and all things being even it should give you a better benchmark with it on. However I did do some checking on your graphics card and it is at the bare minimum for Aero. I would think its being pushed a bit much and that could be the cause why you do not see it as beneficial. Remember I am using a dual monitor setup with different resolutions and it has no problem working with this. This is the hardest graphics setup to support.

Areo was one of the original four Longhorn (now Vista) pillars. The others included .Net (dev environment is built into Vista boxes so you can write, compile and run c# or vb.net code on your Mom's pc), built in sql server express for indexing of file and personal data (think contacts which are now abstracted to the user level rather than being owned by an app). The last was the communication foundation (which has caused much of the driver pain).

Vista is an excellent product and lays great groundwork for a better computing future. App developers like Cakewalk suffer from the change, having to solve probs like enabling the app under least privileged user mode, but for users, it's great!

Cool!

Thanks for taking the time to do this John. But, just to be clear, did you just compare CPU readings in Sonar with/without Aero or did you actually start moving windows around? Don't pay too much attention on CPU readings and just try to make the audio glitch by moving plugin windows around from monitor to monitor. But you first need to open as many Multiband Compressors as the system can handle without glitching. Is this what you did? Did it glitch more with Aeron ON or OFF?

Sorry if I'm being too picky :-)


Thanks!

By the way, this is the test I used:

http://www.aavimt.com.au/downloads/SONARbench%20DSP-R2.rar

This is the official Benchamrk site (for those who want to know):

http://www.dawbench.com/index.html

ORIGINAL: John

Thanks for taking the time to do this John. But, just to be clear, did you just compare CPU readings in Sonar with/without Aero or did you actually start moving windows around? Don't pay too much attention on CPU readings and just try to make the audio glitch by moving plugin windows around from monitor to monitor. But you first need to open as many Multiband Compressors as the system can handle without glitching. Is this what you did? Did it glitch more with Aeron ON or OFF?

I didn't do any of that. I just did a quick test of the project to compare the reading in Task Manager. All things were the same except Aero being on or not. I have 4 cores and I found it hard to read a % of total usage in Sonar. That was all I was testing.

Could you please try it then? Please!!!! [sm=kiss.gif]

I would totally appreciate it .


Thanks, you rock!!!!

Originally posted here... http://msdn.microsoft.com/Longhorn/understanding/pillars/ in 2001?

Avalon Defined
What exactly is Avalon? I like to put it this way: Avalon is to Longhorn as User.dll and Graphical Device Interface (GDI) are to Windows (1.0 through XP). I like this analogy because it underscores the significance of the place of Avalon in the evolution of Windows.
I've heard people say "Longhorn is as big a change as Win95," or, "the Longhorn release will be as big as Win2000." Bigger: Longhorn will be the first time since Windows 1.0 that Microsoft has replaced its entire presentation stack, from HWNDs to the DDI. This replacement, and the opportunities it created, make Avalon the most significant step forward for the Windows presentation platform since its inception. When you combine this with the progress made in other areas of Longhorn, such as in the storage subsystem (code-named "WinFS") and in the communications subsystem (code-named "Indigo"), you begin to realize that Longhorn has the potential of being as monumental as Windows 1.0.
So how did Avalon get to the point where it is today? No, we didn't wake up one morning and say "let's build a new presentation stack for Windows." There were several separate efforts that we consolidated to form the Avalon team: User, GDI, DHTML, and eReader. With this union, we had a great comprehensive view of the problem space.
Avalon is not the first time Microsoft tried a hardware-rendered desktop (Chrome, 1999); nor does Avalon mark Microsoft's first attempt at an element-composition–based UI framework (AFC, 1997); nor is Avalon Microsoft's first .NET graphics library (GDI+, 2000). Avalon is Microsoft's first attempt to do all of these things and more as part of a unified effort. When the Avalon team was formed, we set out to define our mission statement. Avalon's aggressive mission statement includes seven primary goals:
1. Exploit the hardware.
2. Integrate UI, media, and documents.
3. Integrate with the Microsoft® .NET Framework.
4. Enrich the declarative programming model.
5. Focus on element composition.
6. Ensure compatibility and interoperability.
7. Incorporate lessons learned over the last decade.
The Avalon Seven
Exploit the hardware
The Windows presentation platform was created in an era of CGA and EGA monitors with 286 processors screaming along at a whopping 8MHz (with the turbo button pushed on, of course). From 1985 to present, Microsoft has made significant advancements to this platform. Still, these ongoing improvements have been increasingly outpaced by ongoing hardware advancements. Today, the Windows presentation platform barely scratches the surface of the hardware power available to it. Windows did add Microsoft® DirectX® to the mix in 1995 in the form of an SDK addition to help third parties. But User & GDI themselves don't make use of DirectX. In fact, it's only when you're playing a game that you're really utilizing DirectX to take advantage of the hardware. Avalon brings the power of the hardware to the Windows application developer.
Integrate UI, media, and documents
We continue to see developers wanting to incorporate all three of these areas into their applications. From a EULA that shows up with rich formatting and in printable form on application install, to animations that create clearer UI transitions for the end-user, application authors want to add value through meaningful richness. This is why Avalon has concentrated on integrating the programming models for these three areas as tightly as possible. The result yields wins such as: a UI framework that builds directly on top of a Media foundation, UI elements that can be animated on a per-property basis, and documents that can contain UI.
Integrate with the .NET Framework
The primary long-term goal of Microsoft's .NET Framework is to provide a consistent and complete programming model for Windows developers. Avalon is committed to being integrated into the .NET Framework. Microsoft® Windows Forms and GDI+ have taught Avalon the value of this integration. In fact, across Longhorn, it will be hard to find the separation between the new Windows API and the .NET Framework. This is why, when developers ask us, "What should we do while we're waiting for Longhorn?", we tell them, "Move to managed code and target Windows Forms for your presentation needs." There is tremendous value in what is already in the .NET Framework, and Avalon's addition to the .NET Framework has given both parties a significant boost.
Enrich the declarative programming model
Microsoft's DHTML work especially has taught us the value of providing declarative definition of hierarchical content. Declarative definition is a more concise, readable, and maintainable way to express a hierarchy of objects than with imperative code. Windows today provides a rudimentary declarative form for UI in .RC files. Leveraging XML, along with the type extensibility of the common language runtime (CLR), Avalon has created XAML with the goal of using it to define not just content and UI hierarchies, but hierarchies of arbitrary CLR objects. There will always be developers who will choose imperative programming, and the Avalon API gives full access to all of Avalon's power. XAML gives an opportunity for those developers who have found markup to be more approachable, especially for the construction of object hierarchies, to use a markup abstraction over this API.
Focus on element composition
In Windows User today, the application author space and the component author space are separated by a wide chasm. Concepts introduced for the application author are rarely applicable to the component author. Rather, the component author finds herself/himself needing to reinvent the wheel within their component, redefining concepts like render, hit-testing, and input. Avalon has made a huge bet on element composition as the central extensibility mechanism. We've focused on making element composition work for not only the application author, but also for the component author. By taking this mechanism so deep, Avalon has created a smoother progression for the application author needing to move into the component author space.
Ensure compatibility and interoperability
There is a danger when the Windows team utters the word "replacement." Developers ask, "What will happen to all of my stuff written for what you've just replaced?" This is where the history of Windows compatibility should reassure those developers. Historically, changes could only be made to the Windows platform if they didn't seriously impact the functionality of existing applications. That same rule applies here. Interoperability is the key, and Avalon is doing a lot of work to ensure that Windows Forms-based and User/GDI-based applications interoperate with Avalon.
Incorporate what we've learned over the last decade
While we have been able to significantly improve the Windows presentation platform since its inception, there were limitations to how far we could take these improvements. The two main factors that limited us were compatibility and architecture. Compatibility is a great goal to have, but it does limit change. In terms of architecture, for stability and maintainability reasons, you had to justify architectural change with compelling reasons. This meant that some features could not be incorporated into the design because the change was too significant compared to the benefit. So we started to build a list of "cool features that didn't make the bar." The idea was that someday the list would grow to be big enough such that the combined benefit of the items in the list would be worth the cost. I'd be lying if I said that Microsoft never thought that time had come before Avalon. Cairo in the early days of NT was the first time we thought "now's the time." Win+ in the later days of NT was the second time. With Avalon, it turned out that the timing was right. So Avalon drew from this list to construct a powerful and comprehensive feature set, including such enhancements as size-to-content layout, dependency-based property system, rich databinding to any property on any object, navigation and journaling services for applications, and attachable editing services.
Putting It All Together
On January 17, 2001, the Avalon team was formed. Four hundred strong, we stood with these seven goals in hand and tried to envision the road ahead. Starting such a large team to achieve something so different in nature was unsettling. The Avalon team is a four hundred-cylinder engine. When the timing of those cylinders is on, it's going to make for one very powerful engine. But before that happens, you're going to have to spend a lot of time in the garage working on the timing, so that these cylinders don't work against each other. Well, we did spend many months in that garage, but it paid off. Sitting at the PDC last month, we saw the look in people's eyes as they got a glimpse of what this four hundred-cylinder engine had produced thus far. And the feedback we're getting now is the gas for this engine. We came back from the PDC to an energized team that has all eyes on the finish line. Looking back, I can't enumerate all of the right moves that we had to make to get to where we are today. Looking outside of Avalon to the entire Longhorn effort, it's even harder to articulate how we managed to put all of this together. But the feeling of accomplishment is incredible.
As you begin to dig into the bits that we delivered to you at the PDC, keep saying to yourself, "pre-alpha release." I'm reminding you of this, not to keep you from bashing us when you hit obvious bugs; rather, I'm reminding you of this so that you won't hold back on feedback because you think we're too late to do anything about it. With the PDC, we've opened the floodgates, and we're expecting to get deluged with feedback. So don't disappoint us; let us hear it all, good and bad.
I'd like to close with my personal success metric for Avalon. In my mind, Avalon will be a huge success if, at the launch of Longhorn, the following commercial is aired on every primetime slot (I still haven't come up with the ideal background music for the end of the commercial, but you have my word that it won't be Start Me Up):
Fade in on a 12-year-old boy sitting at a computer. The camera is positioned peeking out from behind the monitor, showing the back of the monitor and the boys face. The boy is slowly moving the mouse around and clicking. With each click, he exclaims, "Woah ... sweeeet ... beautiful." Fifteen seconds pass.
Enter Mother, stage left, coming in with a smile on her face, calling, "Jimmy, I'm back." Mother's smile turns to a look of shock as her eyes meet the screen. She hurries her last two steps to Jimmy's side, saying, "Well I never!" as she brings her hand to cover his eyes. Mother then uses this hand to turn Jimmy around in his chair until he's facing her.
The camera changes to peeking out from behind the Mother, showing her side and focused directly on Jimmy. Mother lifts her hand as Jimmy looks up at her and says, "But mom, it's just Windows." The camera pans to show the monitor with Longhorn running with "living windows" that make your eyes pop. Jimmy's voice fades out as he continues explaining to his mom. Fade in text with voiceover: Microsoft's New Windows: too sexy?

Inside Avalon
Jeff Bogdan joined Microsoft in 1991 as a developer in Windows. Today he is an architect on the Windows Client Platform team working on Avalon. He is responsible for the design and developer experience of the presentation components in Windows. When he's not playing with computers, he's playing with his two sons, relaxing with his wife, or inline skating as fast as his legs can propel him.
Chris Anderson joined Microsoft in 1997 as a developer in Microsoft® Visual Basic®. Today he is an architect on the Windows Client Platform team working on Avalon. He is responsible for the design, developer experience, and architecture of the presentation components in Windows. Lately he is working on perfecting his rollerblading and Halo skills. Chris' wife puts up with his addictions, including digital photography, blogging, video games, and home theaters.

Gswitz thanks for that. Its nice to be backed up by MS on this. I have tried to explain this in words I can understand and I am not a geek type though some would think I am. I try to understand the underlying concepts not so I can regurgitate them but so I can get a conceptual model in my own mind. That way I can figure it out and in my own way understand it. This was not that hard to figure out but it did take me doing a little research and it also took the help of others to solidify it in my own mind. Timor was very helpful in this process. I owe him a lot in this.

John,

The MC's don't do anything graphical by themselves but they do when you start moving them constantly from screen to screen. Your graphics will definitely be working hard then, specially when the system is being pushed to its limits. If Aero does work as advertized then it should be able to cope with the strain better than if it was OFF. This is not a, "let's see who's system is better" test, but a test to confirm and validate that Aero does work by offloading graphical cycles from the CPU. Thanks so much for taking the time to do this John. I really appreciate it.


Take care!

ORIGINAL: Jose7822

John,

The MC's don't do anything graphical by themselves but they do when you start moving them constantly from screen to screen. Your graphics will definitely be working hard then, specially when the system is being pushed to its limits. If Aero does work as advertized then it should be able to cope with the strain better than if it was OFF. This is not a, "let's see who's system is better" test, but a test to confirm and validate that Aero does work by offloading graphical cycles from the CPU. Thanks so much for taking the time to do this John. I really appreciate it.


Take care!

I was talking about the meters in them and the moving graphics that are updated in tiny intervals. I do understand what you were asking thats why I did it. I could not say anything without me doing those tasks.

There was an interesting article in PC Gamer, I think, about this. The gist of the article being that video cards will soon become the workhorse of PC's, freeing up the CPU for gobs of multi-tasking power. The future looks good... if not horribly expensive.

I didn't want to say it but we owe a lot to gamers. They have pushed the envelope to a great degree. If not for them we may not have seen this this soon. The hardware is here now and Nvidia has a system that will directly access the GPU for computing. You do need the right card from them and the apps that support the programing but its here now.

Not only the expesive line of NVidia cards work fine with Aero On. I have a simple GForce 8600 GT, with 512Mb DDR 2 onboard memory. It isn´t DX 10 compatible, but I have only good experiences with Aero turned ON. No glitches, pops or any problem running heavy projects and moving/opening/closing windows in both monitors (2).
I´m running Vista Ultimate SP1 x64, 4Gb DDR2 800 memory (2x2Gb) in dual mode, Intel E8400 3GHz/1333 FSB processor, Intel DP35DP motherboard, 3 SATA2 HDs, M-Audio Firewire 1814 audio/MIDI interface (running the x64 beta drivers). No problems, very happy with this system.
Greetings.