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?

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.