Did you know: All GDI apps render slower under Win7?

[Max Norris]

That would imply that no single driver release for the past year, either from NVIDIA or AMD, have proper ION or Radeon 4250M support for Windows 7....

Not implying anything of the sort. What I am implying is that sometimes drivers are buggy. It happens. This system that I'm currently sitting at is using an old ATI HD 3850 AGP, and last month's drivers caused a couple issues, rolling back to the version from the month before took care of it. Hence.. "driver issues".

[Tilt090]

ahhh this is why windows just didnt feel fluid enough. tried going back to winxp and i can confirm this result. IPS screens additionally produce some input lag combined with this it feels we went behind in terms of fluidity of gui experience over last 7-8 years.. not to flare things up but damn that was a total waste of time th last decade trying out different windows versions, upgrading to IPS screens etc when everything works great with old tech.!!!

[Tilt090]

questioOP how does disabling aero affect windows 7 aero performance when compared to winxp gdi drawing? is xp still 5 times faster? i reckon the gap would be smaller.

[Tilt090]

quoting from the OP "On the other hand, not using DWM will free up a lot of CPU resources. But still not enough to make GDI render operations as fast and responsive as Windows XP, as XP has more CPU free to do other tasks."

ok got my answer :)

[Aethec]

Lol what? That is from a Windows 7 WinHEC presentation which simply says Direct2D will replace GDI for new apps which it has already. Doesn't mean all GDI apps will transform themselves into Direct2D apps without developers rewriting them. GDI is deprecated as of Windows 7 (2009) because WPF was a managed code platform meaning all native code apps written from the beginning of Windows to 2009 and the dozens being written today still use GDI.

Sorry, try again.

Since GDI is an API, the back-end is not important to developers using it. If it was migrated to be a thin layer above DirectX, all existing GDI apps would "just work", just like all GDI apps written for XP "just work" when ran on Vista/7 even though the GDI isn't hardware-accelerated any more. Look at the patent I mentioned, it's pretty explicit : redirecting calls from one API to another one, in the context of graphics rendering.

Also, WPF has nothing to do with this. The successor of GDI is DirectX and its new set of APIs introduced in Win7 and backported to Vista such as Direct2D and DirectWrite, WPF is just a managed framework to develop hardware-accelerated apps.

The idea of abandonning GDI is not new ; in your beloved XP, Windows Explorer's right pane (the one with collapsible regions showing possible actions) is done using DirectUI, an undocumented proprietary framework from Microsoft (which uses XML files, making it a WPF predecessor for native code) that is hardware-accelerated and doesn't use the GDI at all.

[Zain Adeel]

i dont care about whats going on underneath. But i always thought this white black mess when we resize was present in every windows to date :p

i didnt realise it was not in XP.

Now i think about it. Was the design team sleeping? First those OLD icons... they bug me to death. And also this.

I never actually see this unless i drag my explorer window and there u can see a black and a white box next to the search bar. I mentioned it before somewhere. And its really annoying. I dont understand why is this not fixed. As it was there in Vista. And i havent tried to see if its there in Win8. Can anybody test?

[MS Bob 11]

Since GDI is an API, the back-end is not important to developers using it. If it was migrated to be a thin layer above DirectX, all existing GDI apps would "just work", just like all GDI apps written for XP "just work" when ran on Vista/7 even though the GDI isn't hardware-accelerated any more. Look at the patent I mentioned, it's pretty explicit : redirecting calls from one API to another one, in the context of graphics rendering.

Also, WPF has nothing to do with this. The successor of GDI is DirectX and its new set of APIs introduced in Win7 and backported to Vista such as Direct2D and DirectWrite, WPF is just a managed framework to develop hardware-accelerated apps.

The idea of abandonning GDI is not new ; in your beloved XP, Windows Explorer's right pane (the one with collapsible regions showing possible actions) is done using DirectUI, an undocumented proprietary framework from Microsoft (which uses XML files, making it a WPF predecessor for native code) that is hardware-accelerated and doesn't use the GDI at all.

Yeah but what's the use of DirectUI if its not publicly documented? There's also Milcore (the undocumented native code rendered for WPF). I mentioned WPF because Microsoft's original vision was to replace GDI with the hardware accelerated Avalon stack and it pretty much does everything Direct2D does and more but being managed code, it didn't see and will never see as much uptake by developers. So MS basically introduced a version of Windows after XP without a proper GDI replacement. It was only in Windows 7 that Direct2D was born and it's only been 2 years after that. Developers aren't going to start Direct2D apps overnight abandoning all their customers on XP. There are like 99% GDI apps and 1% Direct2D apps. GDI is going to be around forever for backward compatibility and there are always going to be more GDI apps than Direct2D apps for a long time which is why Microsoft should take the effort to accelerate all of the GDI functions in WDDM drivers. It will be a very long time before we see apps that are all using Direct2D. And Explorer's left pane uses DirectUI (the Task Pane), not the right pane.

[Udedenkz]

Are there still components in Windows 8 that have issues?

In Windows 7, there is Microsoft Management Console for example.

[The_Decryptor Veteran]

The most important operations are GPU accelerated, but if performance is more important, then they could use Direct2D/Direct3D on Vista/7, and Direct3D on old OSs like XP or 2K (e.g. Firefox renders all web page content on the CPU, and composites it on the GPU on 2K and XP)

GDI is a deprecated technology, so MS isn't going to spend time improving it for old applications.

[Aethec]

Yeah but what's the use of DirectUI if its not publicly documented? There's also Milcore (the undocumented native code rendered for WPF). I mentioned WPF because Microsoft's original vision was to replace GDI with the hardware accelerated Avalon stack and it pretty much does everything Direct2D does and more but being managed code, it didn't see and will never see as much uptake by developers. So MS basically introduced a version of Windows after XP without a proper GDI replacement. It was only in Windows 7 that Direct2D was born and it's only been 2 years after that. Developers aren't going to start Direct2D apps overnight abandoning all their customers on XP. There are like 99% GDI apps and 1% Direct2D apps. GDI is going to be around forever for backward compatibility and there are always going to be more GDI apps than Direct2D apps for a long time which is why Microsoft should take the effort to accelerate all of the GDI functions in WDDM drivers. It will be a very long time before we see apps that are all using Direct2D. And Explorer's left pane uses DirectUI (the Task Pane), not the right pane.

For the last time: GDI can and will be rewritten as a layer above DirectX, thus hardware-accelerating all existing GDI apps without the need to create a new version of WDDM whose point would be backward-compatibility.

Why can't you understand that? You're asking Microsoft to do something they already plan to do, in a way that would be much worse (adding backwards compatibility to WDDM...).

Microsoft's plans for the future include moving to a fully managed OS (Midori), and using virtualization to run older apps. Which implies having the least possible amount of code to virtualize, which implies rewriting old stuff as thin, lightweight layers above the new stuff instead of keeping and maintaining old code.

(PS: Yes, I mean the left pane, not the right one, sorry)

[Tilt090]

For the last time: GDI can and will be rewritten as a layer above DirectX, thus hardware-accelerating all existing GDI apps without the need to create a new version of WDDM whose point would be backward-compatibility.

Why can't you understand that? You're asking Microsoft to do something they already plan to do, in a way that would be much worse (adding backwards compatibility to WDDM...).

Microsoft's plans for the future include moving to a fully managed OS (Midori), and using virtualization to run older apps. Which implies having the least possible amount of code to virtualize, which implies rewriting old stuff as thin, lightweight layers above the new stuff instead of keeping and maintaining old code.

(PS: Yes, I mean the left pane, not the right one, sorry)

please drop me a line when its done, right now going back to xp feels like a breath of fresh air. seriously drop me a pm when this gets done win7 is great too but ill be on xp for the while. cheers.

[Udedenkz]

For the last time: GDI can and will be rewritten as a layer above DirectX, thus hardware-accelerating all existing GDI apps without the need to create a new version of WDDM whose point would be backward-compatibility.

Why can't you understand that? You're asking Microsoft to do something they already plan to do, in a way that would be much worse (adding backwards compatibility to WDDM...).

Microsoft's plans for the future include moving to a fully managed OS (Midori), and using virtualization to run older apps. Which implies having the least possible amount of code to virtualize, which implies rewriting old stuff as thin, lightweight layers above the new stuff instead of keeping and maintaining old code.

(PS: Yes, I mean the left pane, not the right one, sorry)

Question to ask is why hasn't this been done in 7?

Second question is will this be in Windows 8?

Assuming good design, testing, and optimization, this should speed up my netbook by a large constant factor.

[MS Bob 11]

For the last time: GDI can and will be rewritten as a layer above DirectX, thus hardware-accelerating all existing GDI apps without the need to create a new version of WDDM whose point would be backward-compatibility.

Why can't you understand that? You're asking Microsoft to do something they already plan to do, in a way that would be much worse (adding backwards compatibility to WDDM...).

Microsoft's plans for the future include moving to a fully managed OS (Midori), and using virtualization to run older apps. Which implies having the least possible amount of code to virtualize, which implies rewriting old stuff as thin, lightweight layers above the new stuff instead of keeping and maintaining old code.

(PS: Yes, I mean the left pane, not the right one, sorry)

There is nothing that says in the patent or PPT slide that clearly says it applies to versions of Windows later than Windows 7, in fact the patent and the PPT are from 2009. Neither has MS officially written anything on this, MSDN or elsewhere. Why can't you understand that unless you work on the graphics team in Windows and speak for Microsoft, saying "it will return" is only wishful thinking. I will believe it when I see it working in a future release. Information released at //Build/ about WDDM 1.2 doesn't mention it either though I would be glad to have been proven wrong if MS surprises by announcing full GDI acceleration is returning in Windows 8. Future/planned concepts does not always end up in shipping products.

[neufuse Veteran]

I remember in the windows 7 beta, they talked a lot (internally) about GDI calls being redirected in DWM as an accelerated function of Direct2D... not everything was transitioned to this but a lot of it was, we had performance tests and everything to test out to make sure it was working at full speed

[The_Decryptor Veteran]

Making GDI run on top of Direct2D probably wouldn't work that well, it's an really old API and probably has a bunch of corner cases were the behavior differs from Direct2D, and implementing code to special case those issues would slow any re-implementation down.

But again, GDI is old, why would MS spend time fixing and enhancing it, when they've replaced with with Direct2D?

[neufuse Veteran]

Making GDI run on top of Direct2D probably wouldn't work that well, it's an really old API and probably has a bunch of corner cases were the behavior differs from Direct2D, and implementing code to special case those issues would slow any re-implementation down.

But again, GDI is old, why would MS spend time fixing and enhancing it, when they've replaced with with Direct2D?

because even to this day people are still writing code in GDI and GDI+, until I can go into .NET and say make a new brush and a rectangle with a texture fill brush in Driect2D without having ti reference Direct2D people will use GDI+ you have to write wrappers that force all those calls through Direct2D almost every windows control is written in GDI or GDI+ very few are written in Direct2D even to this day

[Aethec]

Question to ask is why hasn't this been done in 7?

Second question is will this be in Windows 8?

Assuming good design, testing, and optimization, this should speed up my netbook by a large constant factor.

That's a good question. I don't know the answer, of course, but I think we can assume that all of these "why don't they optimize feature X" questions have the same answer - they had more important stuff to do.

Seriously, when was the last time you noticed a big slowdown because of GDI being software-powered?

@neufuse: Are you talking about WPF or WinForms? WinForms is a layer above GDI, but you should be able to do this kind of stuff in WPF.

[~Johnny]

because even to this day people are still writing code in GDI and GDI+, until I can go into .NET and say make a new brush and a rectangle with a texture fill brush in Driect2D without having ti reference Direct2D people will use GDI+ you have to write wrappers that force all those calls through Direct2D almost every windows control is written in GDI or GDI+ very few are written in Direct2D even to this day

Or, you could just use WPF with NET, seeing as it's visual stack uses DirectX, and all DIrect2D does is map itself on to DirectX / Direct3D anyway :p Unfortunately, it shows that it's building on DirectX - the amount of code you need just to get a Direct2D Windows up and running is nearly the same as a DirectX / Direct3D Window - though Microsoft do seem to be pushing .NET more anyway, and that's the life of trying to code native Windows applications. Hassle.

[neufuse Veteran]

Or, you could just use WPF with NET, seeing as it's visual stack uses DirectX, and all DIrect2D does is map itself on to DirectX / Direct3D anyway :p Unfortunately, it shows that it's building on DirectX - the amount of code you need just to get a Direct2D Windows up and running is nearly the same as a DirectX / Direct3D Window - though Microsoft do seem to be pushing .NET more anyway, and that's the life of trying to code native Windows applications. Hassle.

you COULD use WPF, but that still leaves all the MFC coders, the Win32 coders out in land of generally using GDI... and .NET coders generally use the forms based development approach not WPF, until MS says forms is dead and WPF is the standard this isn't going to change... we still use forms where I work, because its what we've done for ever, and when you work in the IDE the forms approach just seems easier, WPF has a lot of stuff that needs worked on still in the IDE to make it perfect for visual development

@neufuse: Are you talking about WPF or WinForms? WinForms is a layer above GDI, but you should be able to do this kind of stuff in WPF.

Forms, yes.. the most commonly used development method, WPF is slowly growing but its no where near forms, and doesn't have as many 3rd party controls premade for it either... although Devexpress is making some inroads on that though

[~Johnny]

you COULD use WPF, but that still leaves all the MFC coders, the Win32 coders out in land of generally using GDI... and .NET coders generally use the forms based development approach not WPF, until MS says forms is dead and WPF is the standard this isn't going to change... we still use forms where I work, because its what we've done for ever, and when you work in the IDE the forms approach just seems easier, WPF has a lot of stuff that needs worked on still in the IDE to make it perfect for visual development

Using Visual Studio to create WPF interfaces is a pain for sure... using Microsoft Expression Blend though and it's much closer to a joy :p Shame they don't appear to be doing much too update WPF though. With all these massive performance enchancements they do to browser engines these days, you'd think they'd go in and try to do something similar with the .NET framework. Aww well.

[Joey S]

I dunno, I've had a pretty easy time with it in C++.

That's because it's written in C++ lol. Why do you think I said C, and not C/C++. Using any of the Direct* interfaces in C is horrible because they all use COM.

Very well documented on MSDN. Plus you can mix and match GDI with Direct2D, also well documented on MSDN. Of course there's a learning curve, always is with the new and improved API's.

I'm sorry but nothing will ever get me to use COM or the Direct* interfaces. At least the GDI and Win32 interfaces are C friendly, COM and Direct2D by relation most certainly aren't.

[+Warwagon MVC]

yep this is why the default theme on a Vista / 7 system that doesn't support Aero Runs like TOTAL ass GUI wise. Where as the GUI on a windows XP system runs great.

[The_Decryptor Veteran]

because even to this day people are still writing code in GDI and GDI+, until I can go into .NET and say make a new brush and a rectangle with a texture fill brush in Driect2D without having ti reference Direct2D people will use GDI+ you have to write wrappers that force all those calls through Direct2D almost every windows control is written in GDI or GDI+ very few are written in Direct2D even to this day

GDI+ isn't a layer on top of GDI or such, it's a different engine entirely (GDI+ runs entirely in software, which is why you can use it on 9x and such). But even then you still have to reference GDI+ to use it in .NET apps (Through System.Drawing)

And while the normal Windows controls use GDI, that doesn't mean programs have to (Look at Firefox, the entire UI is drawn through Direct3D), and eople who care about performance aren't going to be animating buttons and text boxes (and those who do care about performance and are still using GDI for some reason, would most likely be using Direct3D or such to composite it to save re-rendering)

[Max Norris]

That's because it's written in C++ lol. Why do you think I said C, and not C/C++. Using any of the Direct* interfaces in C is horrible because they all use COM. I'm sorry but nothing will ever get me to use COM or the Direct* interfaces. At least the GDI and Win32 interfaces are C friendly, COM and Direct2D by relation most certainly aren't.

So you're refusing to use the official API's provided to access these systems, never mind ignoring the tools that the platform was written in to begin with, then going to cry about how hard it is to use? Yea, that makes sense. :argh:

[Joey S]

So you're refusing to use the official API's provided to access these systems, never mind ignoring the tools that the platform was written in to begin with, then going to cry about how hard it is to use? Yea, that makes sense. :argh:

What?? GDI and the Win32 API's are official. The Direct*D API's are not a requirement to build Windows GUI's. You do know that right?