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


Recommended Posts

  On 03/11/2011 at 12:47, Udedenkz said:
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".

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.!!!

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 :)

  On 03/11/2011 at 12:04, xpclient said:

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.

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?

  On 07/11/2011 at 16:55, Aethec said:

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.

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.

  On 07/11/2011 at 17:56, xpclient said:

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)

  On 08/11/2011 at 16:58, Aethec said:

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.

  On 08/11/2011 at 16:58, Aethec said:

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.

  On 08/11/2011 at 16:58, Aethec said:

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.

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

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?

  On 09/11/2011 at 05:00, The_Decryptor said:

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

  On 08/11/2011 at 18:47, Udedenkz said:

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.

  On 09/11/2011 at 16:58, neufuse said:

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.

  On 09/11/2011 at 17:11, ~Johnny said:

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

  On 09/11/2011 at 17:06, Aethec said:

@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

  On 09/11/2011 at 18:59, neufuse said:

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.

  On 03/11/2011 at 12:26, Max Norris said:

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.

  On 03/11/2011 at 12:26, Max Norris said:

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.

  On 09/11/2011 at 16:58, neufuse said:

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)

  On 09/11/2011 at 19:25, Joey S said:
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:

  On 10/11/2011 at 12:01, Max Norris said:

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?

This topic is now closed to further replies.
  • Posts

    • Meta says that its "Private Processing technology" will be used. Oh, thank God! Now, I will finally sleep a whole lot better at night trusting FB. 🙄🙄🙄
    • The Teams Admin center is still a mess. I use it all the time. They really need to talk with the Intune or Entra ID folks for help.
    • Senua's Saga: Hellblade II to get 60FPS mode, dev commentary, and more alongside PS5 launch by Pulasthi Ariyasinghe Back in May, Microsoft revealed Senua's Saga: Hellblade II as the next first-party Xbox game to reach PlayStation platforms. Now, that release has an official release date attached to it, and alongside it, developer Ninja Theory is releasing an update across all platforms with some major features, including a 60 FPS mode on consoles. The Performance Mode is easily the biggest addition to the story-focused immersive experience. Ninja Theory is delivering it to both Xbox Series X and PlayStation 5 players, but there is some bad news for Series S owners, as it is being left out from the upgrade. "The result is smoother gameplay, especially noticeable during combat and fast-moving moments of the game," says the developer. It's unclear how much of the game's visuals Performance Mode users will be missing out on compared to the default 30FPS "cinematic" mode. PC players are getting an upgrade too. A Very High preset is being added to the settings menu for those wanting even higher fidelity graphics. Optimizations have also been a focus on PC, and Ninja Theory says that the title will be Steam Deck Verified when the Enhanced update lands in August. Next, similar to the original, Dark Rot is incoming as an optional experience that players can enable when starting a campaign. This will have a rot effect being applied to Senua every time she dies, and if it ever reaches her head, the game will come to an end, with all progress from that save being wiped. The Photo Mode in Hellblade II is being upgraded with this update too, with the studio touting a new Motion tab for cinematic video capture, as well as improvements across the board to the feature. Lastly, four hours of developer commentary is being added to give a behind-the-scenes look at how the studio crafted the story and gameplay. "Hear from the ensemble cast, key collaborators in depicting Senua’s experience of psychosis, and members of the development team who poured their heart and soul into Senua’s story," says the studio. The Senua’s Saga: Hellblade II Enhanced comes out on August 12 across PC, Xbox Series X|S, and PlayStation 5 for all owners and Game Pass subscribers as a free upgrade. As for the PlayStation 5 launch of Senua’s Saga: Hellblade II that's happening on the same day, Microsoft will be offering two versions: Standard and Deluxe. As expected, Standard includes the complete base game for $49.99, but Deluxe goes further by adding on a copy of the first game, Hellblade: Senua’s Sacrifice, as well as its original soundtrack. The Deluxe Edition costs $69.99 to purchase.
    • Not sure what you’re talking about. Has been there for quite a while and in the latest versions it’s actually quite good. I use it several times a day as I am a terrible typist.
  • Recent Achievements

    • Rising Star
      Phillip0web went up a rank
      Rising Star
    • One Month Later
      Epaminombas earned a badge
      One Month Later
    • One Year In
      Bert Fershner earned a badge
      One Year In
    • Reacting Well
      ChrisOdinUK earned a badge
      Reacting Well
    • One Year In
      Steviant earned a badge
      One Year In
  • Popular Contributors

    1. 1
      +primortal
      549
    2. 2
      ATLien_0
      209
    3. 3
      +FloatingFatMan
      172
    4. 4
      Michael Scrip
      152
    5. 5
      Som
      142
  • Tell a friend

    Love Neowin? Tell a friend!