I'm attempting to write a small screen capture utility that writes captured video to disk.

First, I get the front buffer surface. I've written a shader that takes this surface and through render to texture, converts it to a YUY2 format frame. The format change is required so that I can pass the frames off to an encoder.

I'm using DirectX 9 to acquire the frontbuffer. There are a couple of ways I know of to get at the front buffer:



The MSDN page on both of these API calls state that the data is copied from device memory to system memory. I'd like to copy the front buffer surface directly to another graphics memory surface, as I have other manipulations to perform on the acquired surface before returning it to system memory.

I'm creating a D3DUSAGE_DYNAMIC texture (gfx mem texture) and calling GetFrontBufferData() to write the front buffer to my textures surface0. Is this valid? Will the operation remain in gfx memory, or will it need to move to system memory and then back to graphics memory? If this is the case, is what I'm trying to achieve possible?

EDIT I've been acquiring the front buffer as below, simply because its a convenient way to get a surface populated:

hr = Dx9Mgr::Ref().D3DDev()->GetFrontBufferData( 0, m_spCaptureSurface );

OTOH, GetBackBuffer() allocates a new surface (I want to reuse one over and over), so I just went with GetFrontBufferData().

GetRenderTargetData() requires that the destination surface be created in system memory rather than in gfx memory (e.g. uses D3DPOOL_SYSTEMMEM ), so I ruled this out. Maybe I should reconsider?

  • \$\begingroup\$ This doesn't appear to be particularly game related other than using D3D, and since you're asking about making a screenshot program I think you will find better responses on StackOverflow. \$\endgroup\$ – user1430 Jan 3 '14 at 15:48

GetFrontBufferData is documented as being incredibly slow and unsuitable for use in any performance-critical path. In general terms the front buffer is something that belongs to your display subsystem and your program normally does not have access to it.

It's highly likely that there is a much better way of achieving the result you want without needing to access the front buffer at all. From the sound of it, you're talking about something that can be solved by a completely standard render-to-texture setup, but you'd need to give much more info on what it is you're trying to do before anyone could comment further.

  • \$\begingroup\$ I've updated my original question to include more information about what I'm doing. \$\endgroup\$ – lapin Jun 12 '12 at 13:10

Not the answer you're looking for? Browse other questions tagged or ask your own question.