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


Recommended Posts

Okay this is well known since Vista and Windows 7 came out but just to make some of you aware who might now be knowing:

Some information :

http://msdn.microsof...0(v=vs.85).aspx

http://blogs.msdn.co...2d-and-gdi.aspx

http://blogs.msdn.co...in-windows.aspx

http://www.passmark....performance.htm

And some benchmarks:

Part 1: http://www.tomshardw...s-gdi,2539.html

Part 2: http://www.tomshardw...gdi,2547-1.html

And some demos:

What they're all basically saying:

Under Windows XP, GDI is fully hardware-accelerated by the GPU. Windows Vista removed GDI acceleration completely and therefore GDI runs on the CPU without any optimization. Under Windows 7, GDI runs on the CPU, but is partially accelerated, a very small subset of operations are optimized to be faster. Specifically, only 6 operations are accelerated out of hundreds of GDI operations.

So how does this correspond to graphics performance? GDI has been used from the very beginning of Windows until now. It's "the" main tool to draw interface elements and other such things in Windows. So to say... your web browser, your IM windows, your Explorer interface, the Control Panel, the widgets on your desktop, most of them use GDI to draw their interfaces. The only exceptions are applications that support Direct2D, which have recently come out: Firefox 4, and Internet Explorer 9. So GDI is used to draw pretty much... everything. What about those transparent/glass frames in Windows 7? Well, they're part of the new Desktop Window Manager (DWM) process, which acts as an overlay to the underlying windows.

DWM redirects window draw routines to an offscreen buffer and then re-draw them back to the main screen. That means for any window, DWM is redrawing their contents... twice. Coupled this with slower GDI performance than Windows XP. On the other hand, DWM will ensure the contents of the window fit in before it redraws the whole window, so when you drag the window around, it won't cause graphical glitches because now the window will only be redrawn when it's complete.

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. If there is a fix for this, I would love to know, too... but it seems like this is already an integral part of Windows 7. The driver model has had to be rewritten to accomodate the new driver device interface (DDI) of DirectX 10 and beyond, and they had to shaft GDI hardware acceleration to accomplish that. They chose to remove GDI hardware acceleration as they found it hard to combine both driver model features. So there is no likely fix in the future except for a whole new edition of Windows.

That said, though, it's not all a loss. Developers can move to Direct2D, and bring hardware acceleration back to their Windows 7 applications. The problem is, though, that Direct2D is not so widely accepted. Not a lot of developers feel inclined to use it when most PCs nowadays can handle GDI in their CPUs just fine. Plus Direct2D is a whole new library, so learning it would be like discarding years of knowledge about window interface programming. Even Microsoft themselves are not doing too many things in Direct2D explicitly... except for Internet Explorer 9 no Microsoft app is using D2D AFAIK. Windows Live Messenger, Windows Media Player, Windows Explorer, and the various control panels within Windows 7 are still using GDI to draw their interfaces.

So I think whether or not we'll see smooth applications is entirely up to software developers. So to sum it up for the layman and for those who might not have enough time to read all of the rambling I wrote above:

Windows XP beats Windows 7 hands down when it comes to GDI rendering performance and 99.9 % of apps use GDI. But Windows 7 has less drawing glitches thanks to DWM. Windows Vista/7 do not have hardware accelerated GDI rendering or hardware accelerated audio rendering either (DirectSound).

If Microsoft is banging the IE9 drum about how great it is to have a hardware accelerated browser, it's because it was because IE7 and IE8 were giving slower performance on Windows Vista/7 compared to the same browsers on XP.

Moral of the story: Be informed before you trash XP as having slower graphics rendering. It's only Direct2D rendering which XP doesn't have (and which very few apps use today). GDI and 2D drawing have always been hardware accelerated up to XP even by non-3D hardware. Today, all your GDI apps run slower than XP. And send feedback to Microsoft to accelerate all GDI operations in a future Windows version (WDDM 1.3 or 1.4).

Still couldn't pay me to go back to XP though, there's just so much that 7 does better than XP that a tradeoff for a bit of GUI performance just isn't worth it to me. (Never mind all the annoying quirks and glitches than XP still has.) And that's just old style GUI rendering, doesn't mean the application itself is any faster... more often than not 7 outperforms XP where it really matters, and randomly scrolling a file manager as crazily as possible isn't one of the top criteria.

Wasn't the direct GDI rendering in XP the source of a few security vulnerabilities?

I remember the fix before MS finally got a patch out was to unregister the built-in picture viewer, so quite frankly, to have slightly slower window drawing VS a much better security side with less hardware exploits, it's a worthwhile sacrifice.

I personally have not noticed 7 being slower to redraw than XP other than very slightly during resizing windows (which is par for the course with a compositing window manager).

Anyhow, you might find that the 6 functions which are accelerated might actually make up 50% of the calls in real world usage.

This is obvious and well known.

XP GUI without divers is horribly slow, but with drivers -benchmark wise- it is much faster than Windows 7 GUI.

The black (sometimes white) underframe effect can be seen in virtually everything. When I maximize Opera, I see this effect.

Microsoft simply hasn't bothered hiding this for some bloody reason.

They could have sped up services and policy editors to render significantly faster to make that effect not so horrid - they didn't.

I am also not sure that D2D fixes the issue...

Anyhow, you might find that the 6 functions which are accelerated might actually make up 50% of the calls in real world usage.

True that and Microsoft's claim is exactly that users may not find that noticeable of a difference plus they already have acceleration for the most commonly used functions in Windows 7.

I am not saying go back to XP either. I am making those who dunno aware to send feedback to Microsoft to fully accelerate GDI once again as the entire ecosystem of Windows apps are never going to be rewritten to use Direct2D. :) If GDI is fully hardware accelerated, there would be no slowdown. Graphics manufacturers as Tom's hardware says pay no attention to 2D performance any more in their race to chase the highest FPS for 3D performance.

GDI will be fully hardware-accelerated soon, since they're rewriting it as a layer above DirectX. All existing apps will use Direct2D, DirectWrite and DirectX APIs, via the GDI.

See this MS patent on redirecting graphic calls: http://www.freepaten...20090328080.pdf

and this slide:

.gdifuture_m.jpg

from this presentation: http://download.micr...-t515_wh08.pptx

PS: Like it or not, GDI is old and completely obsolete, and never allowed what Direct2D allows in terms of performance. There's a reason why no browser implements content acceleration on XP (except Opera, which does so using OpenGL and not DirectX)

  • Like 2

GDI will be fully hardware-accelerated soon, since they're rewriting it as a layer above DirectX. All existing apps will use Direct2D, DirectWrite and DirectX APIs, via the GDI.

from this presentation: http://download.micr...-t515_wh08.pptx

PS: Like it or not, GDI is old and completely obsolete, and never allowed what Direct2D allows in terms of performance. There's a reason why no browser implements content acceleration on XP (except Opera, which does so using OpenGL and not DirectX)

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.

The Windows Live Essentials suite does use Direct 2D in certain areas - Windows Live Messenger and Windows Live Mail do for sure, and I'm sure I've heard them mention all the other apps in the suite do too.

DWM also doesn't draw fully twice - it draws once too a bitmap off screen, and then when that's complete it just copies the bitmap for use / composition - it doesn't go through draw operations again. (In effect similar to a standard frame buffer then?)

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.

Not all unmanaged programs use GDI, there are a few that use Direct2D. As a guess most of them are retaining pure GDI mode just for backwards compatibility with XP, until it officially dies off anyway.

Yes we knew this, we knew GDI+ had it's day and Direct2D is meant to be taking over. Unfortunately, we won't see the real benefits until developers kill off GDI all together. Microsoft didn't drop it to **** people over, it's just a legacy system that doesn't fit well with a new method they've come up with. We knew it'd take time, but there are apps out there and they run really nice with Direct2D.

I can confirm this. I've written some GDI apps for Windows, and primitive drawing operations are definitely slow under Windows 7 than XP.

Not all unmanaged programs use GDI, there are a few that use Direct2D. As a guess most of them are retaining pure GDI mode just for backwards compatibility with XP, until it officially dies off anyway.

There's another aspect you're not taking into account. Direct2D is horrible to use from C.

@~Johnny, is it Wave 4 of Live Essentials that you are saying uses Direct2D? Where has MS published this? Btw unfamiliarity with Direct2D also means that most developers still continue to write apps that use good old GDI on Windows 7. Just XP market share reducing won't make developers start writing D2D apps.

There's another aspect you're not taking into account. Direct2D is horrible to use from C.

I dunno, I've had a pretty easy time with it in C++. 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.

A tasty snippet for you:taken...)

With all of the operations that GDI+ added, though, there was no hardware acceleration support for the operations that it performed.

It's funny how they complain about how GDI rasterizes in on the CPU, and Direct2D has the advantage of doing it using the GPU, but Silverlight on Windows Phone does it on the CPU too which is one of the main CPU bottlenecks on the app platform there :/

It may render imperceptibly slower. BUT on screen for the user windows 7 performs faster and smoother. And that's the important part. The user doesn't care that some rendering they don't see or notice because it happens so fast anyway is slower..

Does DW/D2D really fix anything though?

I have two applications that use D2D: Firefox and IE9.

I have one I am aware of that uses DW: Steam.

Steam is a slow pile of bleep, I see its border shadow and then some time later I see the application draw its own GUI.

Firefox draws its GUI really slowly too, I mean disabling Direct2D actually decreases the time Firefox takes to draw its GUI and before that I either see a white box or a black one.

Both are large, heavily use applications - both suck at GUI rendering speed.

Firefox draws its GUI really slowly too, I mean disabling Direct2D actually decreases the time Firefox takes to draw its GUI and before that I either see a white box or a black one. Both are large, heavily use applications - both suck at GUI rendering speed.

Driver issues maybe? Firefox with D2D enabled is blazing fast on my systems. No stray boxes, no slow GUI, nada. It's fast across the board, and my system is just a healthy "mid-range" setup, nothing fancy.

It is an interesting tidbit, but at the end of the day, it doesn't make a difference for most users. I've never had to switch between controls so rapidly, and the window lag has no effect on functionality.

I did this same Window resize test in Google Chrome on Mac OS X, and it is the same thing (white area, instead of black). Honestly I would have never noticed if it wasn't for this video, I never find myself rapidly resizing windows all the time.

Driver issues maybe? Firefox with D2D enabled is blazing fast on my systems. No stray boxes, no slow GUI, nada. It's fast across the board, and my system is just a healthy "mid-range" setup, nothing fancy.

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

This thread should be composed of people who have CPUs weak enough to notice the GUI lagg on W7.

EDIT: I keep forgetting, but those retard-animations that Windows 7 has mask the problem entirely.

I did this same Window resize test in Google Chrome on Mac OS X, and it is the same thing (white area, instead of black). Honestly I would have never noticed if it wasn't for this video, I never find myself rapidly resizing windows all the time.

I get the white screen too on Windows 7 - However I don't tend to resize windows much, They're usually always maximised or a size that I don't need to resize

Tom's Hardware had written their own 2D benchmark for this called Tom 2D: http://dld.tomshardw.../4eb28f57/59803 but it's very sensitive so it must be run on a clean XP and 7 system. Read their articles first before running the benchmark.

This topic is now closed to further replies.