Urgent: DirectDraw on Windows 8 20ms slower

Category: windows metro apps games

Question

ben.schoerner on Wed, 28 Nov 2012 09:52:23


Hello,

I work at a company distributing a windows software that measures reaction speed in a clinical context.

For us it is extremely important to guarantee that the testing applications run nearly identical on every possible windows machine. From Windows 2000 to Windows 7 we had no problem so far but with Windows 8 we experience a substantial delay : under Windows 8 the stimuli appear around 20ms later than under previous Windows versions (measured with an external device that counts the milliseconds from sending the stimulus to its appearance on the screen). 20ms is much more than tolerable!

We code our software in C++ and use DirectDraw functions. I've read that with DirectX 11.1 DirectDraw calls are realized by some kind of "warp-device"

- Is this WARP-device the reason for the delay?

- Is there a way to bypass or accelerate this process?

Thank you very much for your help,

sincerely,

benschoern

 


Replies

henador on Wed, 28 Nov 2012 13:42:56


Is this a Desktop program or a Metro program? Regardless of the app type, that 20ms delay sounds suspiciously close to the VSYNC time on a 60Hz display. My guess is that Win8 is updating the frame buffer on vertical retrace while previous versions updated it on the fly. I would recommend using FullScreen Direct3D with VSYNC enabled on the Present call. That should give you more consistent results across Windows versions and computer hardware.

Chuck Walbourn - MSFT on Wed, 28 Nov 2012 20:43:07


Have you read through the Windows 8 and Windows Server 2012 compatibility cookbook?

DirectDraw is a legacy API that is subject to more and more emulation over time. You should consider using Direct3D 11 on Windows Vista/Windows7/Windows8 instead of DirectDraw.

Chuck Walbourn - MSFT on Thu, 29 Nov 2012 02:04:08


Did you rely on disabling Desktop Window Manager on Windows Vista / Windows 7? This is no longer an option on Windows 8.

ben.schoerner on Thu, 29 Nov 2012 14:17:10


Thank you all for your answers.

 @Chuck: No, we didn't disable the Desktop Window Manager but our application runs with real-time priority. Maybe this is why we didn't have problems with the DWM so far. - I have the feeling that under Windows 8 switching out off the program (for example by pressing the Windows-key) happens much faster than it did under Windows 7. Does the DWM have a higher priority under Windows 8? And is there a chance to control the DWM-priotity?

Do you think the DWM could be responsible for the delay or do you think it's more likely that it comes from the emulation of the DirectDraw routines?

Chuck Walbourn - MSFT on Thu, 29 Nov 2012 18:12:42


Are you trying to 'Lock' the primary DirectDraw buffer?

My guess it is the combination of using legacy APIs with the Windows 8 'always-on' DWM.

On Windows 8, Windows 7, and Windows Vista you should be much more robust by using Direct3D 11 to render and then take advantage of DXGI's GetFrameStatistics to get the actual rendering delay to account for.

ben.schoerner on Fri, 22 Feb 2013 08:50:56


Hello Chuck,

thank you again for your helpful answer.

I finally managed to integrate the Direct3D-routines in our application and I really do get the same fast rendering via Direct3D that I was used to from DirectDraw under Windows 7. This is fantastic!

I'm using DirectX9 to guarantee downwards compatibility for engines with graphics boards that don't support DirectX10 and higher. And I render my bitmaps directly to the backbuffer (D3DXLoadSurfaceFromFile -> StretchRect -> Present) this works fine and seems to be the fastest way to get my bitmaps on the screen.

Just wanted to give some feedback :)


Chuck Walbourn - MSFT on Fri, 22 Feb 2013 20:10:08


As it is, you've traded up from one legacy API to another so you may well hit similar performance issues in a future OS if you stick with Direct3D 9.

NOTE: With the Direct3D 11.x Runtime on Windows 8, Windows 7, and Windows Vista you already have support for DirectX9 era hardware through Direct3D 11 feature levels. This already covers essentially all video hardware that has a WDDM driver.

ben.schoerner on Sat, 23 Feb 2013 07:46:58


Yes, you are right. I considered the risk that an upcoming new Windows could suddenly no longer support DirectX9 and I honestly tried to use DirectX11 - but I made the experience that a simple sample program that draws an ordinary shaded triangle in the middle of the screen worked flawlessly on my Windows7-PC but did not work on the Windows8 machine. It took me nearly a whole day to figure out that the reason was the video card not supporting DirectX11...

So to reach my goal to guarantee our customers a reliable reaction time measurement, regardless of the OS and the capabilities of the video adapter, choosing DirectX9 seemed to be the best solution.

But the feature levels of Direct3D 11 seem to be the perfect solution! I didn't know about this technology - thank you for the hint!

By the way - what do you think would be the fastest way to get a simple 2D monochrome bitmap on the screen under Direct3D 11? Is it still possible to simply copy a surface to the backbuffer or do I have to create a rectangle with the bitmap as texture? Or should I even rely on Direct 2D?

Thanks for your help!