Redirecting GDI, DirectX, and WPF applications

re: Redirecting GDI, DirectX, and WPF applications

Princess — Wed, 03 May 2006 09:51:42 GMT

"DirectX applications only need a single window buffer"

So what happens if the application is halfway through rendering its window and simultaneously a translucent window above it notifies the DWM to begin composition? The contents of the underlying window is required but is not ready.

re: Redirecting GDI, DirectX, and WPF applications

Adrian — Wed, 03 May 2006 17:50:22 GMT

How would someone write a screen-shot grabber in the new model? With traditional GDI, you'd just grab the handle to the screen DC (GetDC(NULL)) and blit from it.

re: Redirecting GDI, DirectX, and WPF applications

Dflare — Wed, 03 May 2006 18:36:38 GMT

How would OpenGL ( or others GAPIS ) work in the new model?? It seems that they try to get exclusive access to the video card??, Would it work on cooperative mode ??

re: Redirecting GDI, DirectX, and WPF applications

Kor Nielsen — Wed, 03 May 2006 18:43:09 GMT

If I understand your post correctly, this will result in significantly increased CPU usage for GDI applications, especially those performing operations with device-dependent bitmaps.

According to my (limited) understanding of GDI as used in today's operating systems, many of the common GDI methods are hardware accelerated. For example, I can create a device-dependent bitmap which is stored in video memory, I can then blit that bitmap to my window's GC, and the entire operation will be performed by the video card.

Suppose I wrote a GDI application which used the subset of GDI commands which can be easily hardware accellerated (mainly DDB blits, solid rectangles, and text output). Why should this application be crippled on Vista? Why can't Microsoft implement GDI on top of DirectX, perhaps failing back to the setup described in your article for apps which use the nasty operations (raster ops and vectors)?

I love how fast GDI is today in comparison to Quartz and X11. Today, I can write a realtime audio processing application, with constantly updating GUI controls, and be confident that the graphics card will take care of almost all the drawing, leaving the CPU available for intensive realtime DSP.

With Vista, it appears that this will all change. All the drawing will be done by the CPU into a system-memory bitmap, similar to Quartz 2D(ugh).

It sounds as though I will have to write two version of my application for maximum speed: one using DirectX for Vista, and another using GDI for older versions of windows.

re: Redirecting GDI, DirectX, and WPF applications

Anonymous — Wed, 03 May 2006 23:44:52 GMT

Kor Nielsen, nah, you don't need two version. DirectX, if used correctly, is pretty much always WAY WAY WAY faster than GDI even on older Windows versions, so switch to that and your app will run smooooth on any computer with a decent graphics card.

re: Redirecting GDI, DirectX, and WPF applications

GRiNSER — Thu, 04 May 2006 00:26:04 GMT

Kor Nielsen, why don't you use WPF? :P

re: Redirecting GDI, DirectX, and WPF applications

Kor Nielsen — Thu, 04 May 2006 03:28:55 GMT

Anonymous/GRiNSER:

I agree that on a modern PC with a $100 graphics card, DirectX (or OpenGL for that matter) will be significantly faster than GDI, with more eye-candy to boot.

Unfortunately, not everyone has a decent graphics card. Many of the machines being sold today have terribly sub-par graphics, and there are plenty of 4-year-old machines with no 3D accelleration that are still in regular use. However, almost all of the computers in use today are capable of rendering fast graphics through GDI.

WPF might be a solution when it is released, but so far I have not been impressed with its speed or stability. Plus, the above-average memory use of the CLR could be unacceptable by potential customers using the 4-year-old machines mentioned above.

The fact that Microsoft themselves are not using WPF for the Windows Shell makes me suspect that GDI will be the primary graphics API on windows for some time to come. Why shouldn't it run fast?

re: Redirecting GDI, DirectX, and WPF applications

Phaeron — Thu, 04 May 2006 07:15:09 GMT

Simply moving everything to DirectX is not practical for many apps. DirectX has few to no fallbacks. You must check caps bits for exactly the features you use and write your own fallbacks for everything that might be absent. And using Direct3D without a GDI or DirectDraw fallback is a non-starter, because if your application is running under Remote Desktop you have NO Direct3D support guaranteed whatsoever.

What I'm wondering is how the DWM handles DirectDraw. Yes, Direct3D has windowed-mode Present(), but DirectDraw doesn't. I don't have to use a clipper, nor do I have to pass the window to SetCooperativeLevel()... and in fact I *can't*, because SCL() requires a top-level window. So how does the DWM know which child windows are GDI-based and which ones are DirectDraw-based? Does it check for a clipper? Or does any use of DirectDraw simply disable the DWM?

re: Redirecting GDI, DirectX, and WPF applications

Eli — Thu, 04 May 2006 15:24:08 GMT

Phaeron,

It's probably when you flip surfaces. You can't lock the primary surface in DirectDraw and co-exist with the DWM. It will disable Glass for your application.

re: Redirecting GDI, DirectX, and WPF applications

Phaeron — Fri, 05 May 2006 07:09:22 GMT

You can't do an emulated flip in windowed mode in DirectDraw like you can in Direct3D. You can only Flip() the primary surface or an overlay, neither of which I would expect to be supported by the DWM. What you can do, however, is a Blt() from an offscreen surface to the primary surface through a clipper attached to a window. If this isn't DWM compatible, then the only alternative for fast 2D graphics with Aero Glass -- or even just *accelerated* 2D graphics -- is to go 3D. Very few 2D graphics apps have a 3D rendering path, and at this point it's still more work and more compatibility hassle than either GDI or DirectDraw.

Regardless, all of the notes on this page about what does and doesn't break the DWM is valuable information that should go directly into the Platform SDK for Vista.

re: Redirecting GDI, DirectX, and WPF applications

David Hopwood — Mon, 08 May 2006 19:35:49 GMT

Being able to write directly to the screen via GetDC(NULL) defeats the point of the UIPI (User Interface Privilege Isolation) stuff, if I'm not mistaken (imagine a virus writing over the "OK" and "Cancel" buttons of a security dialog so the user will click OK when they meant Cancel). So why not disable it?

Yes, I know this would break some applications. However, as a temporary workaround for apps that write to GetDC(NULL), what you could do is to have it return a DC for a dummy surface, that is composited underneath the layer containing UIPI dialogs. This will also work for apps that only rely on reading stuff from GetDC(NULL) that they have written.

As for screen grabbers, that's a clear security bug. As long as 'Shift-PrtSc' and supported screen readers still work, let any other screen grabbers break.

re: Redirecting GDI, DirectX, and WPF applications

Adrian — Mon, 08 May 2006 23:55:07 GMT

David Hopwood wrote: "As for screen grabbers, that's a clear security bug."

That's not so clear to me. Can you elaborate?

The GDI-based systems, built-in print screen has limitations that can be solved by writing a better one. Why should these custom tools be forced to stop working?

re: Redirecting GDI, DirectX, and WPF applications

David Hopwood — Tue, 09 May 2006 06:56:16 GMT

It's a security bug that unprivileged applications can read the contents of other applications' windows, as they currently can.

re: Redirecting GDI, DirectX, and WPF applications

Adrian — Tue, 09 May 2006 07:06:13 GMT

"It's a security bug that unprivileged applications can read the contents of other applications' windows, as they currently can."

But the solution to that is not to prevent all applications from accessing the screen, just the lower privilege ones. There are lots of valid reasons for screen captures (documenting, automated UI testing, etc.), and it seems this approach is going to break existing tools for these applications.

Will the CAPTUREBLT flag on BitBlt ROP codes be obsolete on Vista? Will it let me capture windows at or below my privilege level?

re: Redirecting GDI, DirectX, and WPF applications

igor1960 — Tue, 09 May 2006 22:23:10 GMT

David Hopwood wrtote:
>>"It's a security bug that unprivileged applications can read the contents of other applications' windows, as they currently can."
<<

While it maybe viewed as a security breach, I don't see how DWM prevents from such breach. It may complicate it,but in fact it may even simplify. I would assume, Microsoft will provide an API to enumerate through DWM window buffers: in fact for sure such API already exists as Windows Task Manager, Application Switcher and etc. alreday utilizes such API (maybe not public for now), by providing images of current Task Windows...
=========================
Anonymous wrote:
<< DirectX, if used correctly, is pretty much always WAY WAY WAY faster than GDI >>
GRiNSER:
<< why don't you use WPF? >>

This is not true that "DirectX is faster then GDI". It all depends on what operation are involved. If we are talking about just bitmap blitting, with no scaling and/or N (x/y, where N is integer)stretching then GDI is usually much faster (especially on current PCIenhanced graphics hardware with 1gbs and higher).
Almost on all modern computer systems, even with the best graphics cards (like Nvidia SLI)
DrawDibProfileDisplay that is based on DirectX, returns in favor of StretchDIBits...
Check this:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/multimed/htm/_win32_drawdibprofiledisplay.asp

re: Redirecting GDI, DirectX, and WPF applications

David Hopwood — Wed, 10 May 2006 03:50:57 GMT

"The solution to that is not to prevent all applications from accessing the screen, just the lower privilege ones."

I was concentrating on the design changes that are needed before it's possible to prevent any apps from reading the screen. Almost all applications should be low-privilege.

"I don't see how DWM prevents [such a] breach. ... I would assume, Microsoft will provide an API to enumerate through DWM window buffers."

Probably, but since that would be a *new* (or private) API, it can apply whatever security restrictions are appropriate with no backward compatibility issues. The problem with GetDC(NULL) is that existing unprivileged apps expect to be able to use it.

re: Redirecting GDI, DirectX, and WPF applications

Gabe — Wed, 10 May 2006 10:21:48 GMT

Most apps run with standard privilege. IE would run with lower privilege by default, and services with UI would run with higher privilege.

Privilege escalation windows run in a different desktop (which appears to be drawn on top of your regular desktop), so it's impossible for any app on your regular desktop to draw on it with GetDC(NULL).

A low-rights window like IE would only be able to access other low-rights windows. Otherwise, I don't see why it would be a problem for any standard privilege window not to be able to read/write any other window. If this were a classified system (in the military sense), you could not have a Secret window reading a Top Secret window, but this isn't a problem for regular apps.

re: Redirecting GDI, DirectX, and WPF applications

Mike — Thu, 11 May 2006 22:52:22 GMT

Just to say it explicitely, reading from GetDC(NULL) is still a supported way to do screenshots. That's basically what happens when you hit the printscrn key. Yes it's a lot slower than it is without DWM but screenshots aren't typically a critical path perf scenario.

Another thing that should be said explicitely is that although everybody calls it some varient of "the GetDC(NULL) issue" it is not the call to GetDC(NULL) itself that is expensive. If all you want to do is get some device caps from the DC then go for it. It's only actual reading and writing that's slow.

DWM &amp; Aero Glass at work

David Boschmans Weblog — Thu, 08 Jun 2006 14:01:48 GMT

When talking about WPF during the Windows Vista ISV Touchdown training a lot of people were interested...

How underlying WPF concepts and technology are being used in the DWM

Greg Schechter's Blog — Fri, 09 Jun 2006 11:26:51 GMT

In the earlier posts I've done on the DWM, there's been a hint of the relationship between it and the...

High DPI Support in Windows Vista Aero

Greg Schechter's Blog — Mon, 07 Aug 2006 10:45:43 GMT

A good amount of ink has been spilled on this blog talking about all the
cost, nuance, impact, and...

Java on Vista: Yes, it Works

Chet Haase's Blog — Sat, 07 Oct 2006 00:24:08 GMT

Let's dispel some odd rumors of late: Java works great on Vista. But let's not stop there; let's also dive into some of the challenges that Vista presented for us to make Java work well.

Java on VISTA - Yes, It WORKS! « AGIDARI’s Blog!

Java on VISTA - Yes, It WORKS! « AGIDARI’s Blog! — Mon, 23 Oct 2006 18:30:49 GMT

PingBack from http://agidari.wordpress.com/2006/10/23/java-on-vista-yes-it-works/

Jay R. Wren - lazy dawg evarlast » Archive » Xorg (Xgl) and Vista

Jay R. Wren - lazy dawg evarlast » Archive » Xorg (Xgl) and Vista — Fri, 10 Nov 2006 00:21:53 GMT

PingBack from http://little.xmtp.net/blog/2006/05/03/xorg-xgl-and-vista/

Tim Anderson’s ITWriting - Tech writing blog » Vista vs XP performance: some informal tests

Sat, 01 Dec 2007 19:09:38 GMT

PingBack from http://www.itwriting.com/blog/?p=430

VistaKnowledge.com » Is Windows Vista slower than Windows XP ? » Windows Vista Desktop Customization & News

Thu, 06 Dec 2007 11:53:44 GMT

PingBack from http://www.vistaknowledge.com/vista-news/is-windows-vista-slower-than-windows-xp/

siwu’s blog » Hacking into Vista’s Desktop Window Manager (DWM)

siwu’s blog » Hacking into Vista’s Desktop Window Manager (DWM) — Sat, 08 Dec 2007 20:23:47 GMT

PingBack from http://siwu.info/66/hacking-into-vistas-desktop-window-manager-dwm.html

Cut the Crap: Classic is slower than Aero (*). | keyongtech

Cut the Crap: Classic is slower than Aero (*). | keyongtech — Sun, 18 Jan 2009 20:38:25 GMT

PingBack from http://www.keyongtech.com/3019785-cut-the-crap-classic-is

Greg Schechter s Blog Redirecting GDI DirectX and WPF applications | Outdoor Ceiling Fans

Sun, 31 May 2009 14:04:48 GMT

PingBack from http://outdoorceilingfansite.info/story.php?id=4719

Greg Schechter s Blog Redirecting GDI DirectX and WPF applications | Outdoor Ceiling Fans

Sun, 31 May 2009 20:07:36 GMT

PingBack from http://outdoorceilingfansite.info/story.php?id=22355

Greg Schechter s Blog Redirecting GDI DirectX and WPF applications | alternative dating

Wed, 17 Jun 2009 11:01:20 GMT

PingBack from http://topalternativedating.info/story.php?id=1279

Greg Schechter s Blog Redirecting GDI DirectX and WPF applications | patio set

Greg Schechter s Blog Redirecting GDI DirectX and WPF applications | patio set — Fri, 19 Jun 2009 13:26:12 GMT

PingBack from http://patiosetsite.info/story.php?id=593

Redirecting GDI, DirectX, and WPF applications

re: Redirecting GDI, DirectX, and WPF applications

re: Redirecting GDI, DirectX, and WPF applications

re: Redirecting GDI, DirectX, and WPF applications

re: Redirecting GDI, DirectX, and WPF applications

re: Redirecting GDI, DirectX, and WPF applications

re: Redirecting GDI, DirectX, and WPF applications

re: Redirecting GDI, DirectX, and WPF applications

re: Redirecting GDI, DirectX, and WPF applications

re: Redirecting GDI, DirectX, and WPF applications

re: Redirecting GDI, DirectX, and WPF applications

re: Redirecting GDI, DirectX, and WPF applications

re: Redirecting GDI, DirectX, and WPF applications

re: Redirecting GDI, DirectX, and WPF applications

re: Redirecting GDI, DirectX, and WPF applications

re: Redirecting GDI, DirectX, and WPF applications

re: Redirecting GDI, DirectX, and WPF applications

re: Redirecting GDI, DirectX, and WPF applications

re: Redirecting GDI, DirectX, and WPF applications

DWM &amp;amp; Aero Glass at work

How underlying WPF concepts and technology are being used in the DWM

High DPI Support in Windows Vista Aero

Java on Vista: Yes, it Works

Java on VISTA - Yes, It WORKS! « AGIDARI’s Blog!

Jay R. Wren - lazy dawg evarlast » Archive » Xorg (Xgl) and Vista

Tim Anderson’s ITWriting - Tech writing blog » Vista vs XP performance: some informal tests

VistaKnowledge.com » Is Windows Vista slower than Windows XP ? » Windows Vista Desktop Customization & News

siwu’s blog » Hacking into Vista’s Desktop Window Manager (DWM)

Cut the Crap: Classic is slower than Aero (*). | keyongtech

Greg Schechter s Blog Redirecting GDI DirectX and WPF applications | Outdoor Ceiling Fans

Greg Schechter s Blog Redirecting GDI DirectX and WPF applications | Outdoor Ceiling Fans

Greg Schechter s Blog Redirecting GDI DirectX and WPF applications | alternative dating

Greg Schechter s Blog Redirecting GDI DirectX and WPF applications | patio set

DWM & Aero Glass at work