• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1526
  • Last Modified:

Using DirectDraw to Capture the Screen - Alternative via Direct3D

I have a function which captures part of the screen and places it into a memory DC using DirectDraw7. I have very specific reasons why I need to use DirectDraw versus GDI to capture the screen and explaining them is irrelevant.

The DirectDraw7 algorithm is very straightforward and works great:



surfDescPrimary.ddsCaps.dwCaps      = DDSCAPS_PRIMARYSURFACE
lpDDrawObject7->CreateSurface( &surfDescPrimary, &lpSurfacePrimary, NULL );


surfDescBBuffer.ddsCaps.dwCaps      = DDSCAPS_OFFSCREENPLAIN;
lpDDrawObject7->CreateSurface( &surfDescBBuffer, &lpSurfaceBackBuffer, NULL );

hr = lpSurfaceBackBuffer->GetDC(&hBSurfDC);

The problem is that I need to support multiple monitors and the latest OSes (from Win2k to Win7). I tried to use the DirectDrawEnumerateEx api to query the monitor's GUID but this function returns DDERR_UNSUPPORTED (as well as DirectDrawEnumerate).

I know that DirectDraw has been deprecated and transferred over to Direct3D9. So I assume that on Vista (for instance), DirectDrawCreateEx,CreateSurface and BltFast are supported, but not DirectDrawEnumerateEx.

This only gives me half of a solution to capture the screen efficiently.

I am looking for alternative to either:

A. Query the GUIDs of monitors attached to the desktop so that I can use them in DirectDrawCreateEx.

B. A similar algorithm through D3D9 to capture the screen efficiently (avoiding the GetFrontBufferData API which is slow by design).

Any expert suggestion?

2 Solutions
Jose ParrotGraphics ExpertCommented:
The aim of DX and other "highlevel" graphics APIs is to turn the applications free of the device dependency. The more you need such low level capture the more your code is device dependent.
In the old times we need to scan rows and columns of the keyboards with our code to discover which key was pressed. Nowadays systems are more and more device independent, say, there are programming layers: the device firmware communicates with the device driver which communicates with the BIOS which communicates with the operating system which communicates with the API which communicates with the application. So, making the application to communicate directly with the hardware is VERY difficult, although not impossible, but your program needs to know all about all the devices. And, as soon you terminate your code, a new device will run not properly until you write thr right code to it.
Jose Parrot
PBERGEOTAuthor Commented:
I found out that specifying a NULL GUID to DirectDrawCreateEx returns access to the full desktop (and not just a monitor). From there I use absolute coordinates to capture the desired parts of the screen.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now