DXGI Desktop Duplication Screen Capture Speed [closed]

Question

I am using AcquireNextFrame from the Desktop Duplication API to capture the screen. The refresh rate of the screen is 120Hz. When running a game at 120FPS, the screen capture can capture frames at 120FPS. But when increasing the frame rate of the game to 240FPS, the screen capture actually drops to around 70FPS. My guess would be that the extra frames are being accumulated which adds an overhead, but I am not sure. Is there a way to avoid this performance drop?

Pyx

Do some rough maths: what's the maximum transfer rate for video memory to system memory vs. how much bandwidth 240 fps (at your chosen resolution) requires. I bet you are overloading the memory bus. – Lux

@RichardCritten: Desktop Duplication itself does not do video to system memory transfers. The API consumer might do the transfers though. – Fluker

This is not a question about "general computing hardware and software". Judging by their profiles, not a single one of the close-voters even has sufficient domain-specific knowledge to understand the question. Voting to re-open. And if this were possible, I'd also vote to suspend every single close-voter's account for vandalism. – Rocket

The question is on-topic; vote to reopen. There should be some unobvious reason behind closing, such as blindly following other votes, esp. running for respective badges, or lost control over their accounts. – Fluker

It's crap like this why people are turning away from SO. This is a perfectly legit question. – Mesarch

Answer 1

Desktop Duplication API by design accumulates monitor ("output" in DXGI terms) updates until you request them via AcquireNextFrame. The API is not designed to capture every update in first place. Additionally, you don't specify whether you are doing anything else in the AcquireNextFrame loop or you just measuring performance (the language of the question suggest the latter though).

That is, it is quite expected that with a really intensive frontend application output duplication API misses the updates. There is no much flexibility there either. Perhaps the most important hint available MSDN mentions in ReleaseFrame Remarks section:

For performance reasons, we recommend that you release the frame just before you call the IDXGIOutputDuplication::AcquireNextFrame method to acquire the next frame. When the client does not own the frame, the operating system copies all desktop updates to the surface. This can result in wasted GPU cycles if the operating system updates the same region for each frame that occurs. When the client acquires the frame, the client is aware of only the final update to this region; therefore, any overlapping updates during previous frames are wasted. When the client acquires a frame, the client owns the surface; therefore, the operating system can track only the updated regions and cannot copy desktop updates to the surface. Because of this behavior, we recommend that you minimize the time between the call to release the current frame and the call to acquire the next frame.

That is, calling ReleaseFrame earlier or later affects internal behavior of the API. It is either accumulating updates in general or also keeps replicating the actual payload data into duplicated frame resources.

Fluker

What I don't understand is are these accumulated frames lost or is it like a FIFO queue ? Because when the accumulated frames count rises because of performance issues on the machine, it seems it never goes down when the machine goes back to normal and we continue to acquire successfully. – Vulcan

@SimonMourier: the operating system maintains a side copy of composed desktop frame. Just a copy resource (texture) for your desktop duplication session, without any queuing. AcquireNextFrame/ReleaseFrame is the way to cooperatively work with the OS accessing this resource. Between the two calls the texture is yours and the OS is tracking dirty parts. Outside of Acquire/Release the system also updates the texture besides the tracking. – Fluker

That is, performance wise, with a slow acquirer the system simply overwrites the changes in this copy texture until next AcquireNextFrame call arrives. The MSDN quote above explains that OS will stop updating the texture (just keeping a track of what areas require an update later) until ReleaseFrame call, and this way late releasing helps to prevent having excessive updates - there will be a single joint update later when the copy texture is released. – Fluker

Thanks! I was missing the "side copy" concept. – Vulcan