0

I find that Microsoft's decision to provide cursor updates in the AcquireNextFrame loop causes a huge performance hit when the cursor is being moved around.

When I turn on a millisecond-level clock in the browser, AcquireNextFrame can capture 60 frames of data, and the interval between each frame is very average, but if the mouse moves frequently, the captured data will be less, and the interval between each frame is very uneven.

I found that someone asked this question earlier than me on https://www.reddit.com/r/VFIO/comments/f22k6u/windows_capture_performance_dxgi_bug/

Is there any way to make the function AcquireNextFrame work around this performance issue?

Roman R.
  • 68,205
  • 6
  • 94
  • 158
yanrk
  • 49
  • 5
  • Not sure I understand your problem. AcquireNextFrame is not a capture/screenshot API. It's an API that copies the current desktop image (of bits of it) and/or mouse info to a buffer queue. If the screen refresh is 60hz, it may copy up to 60 images per second but it very depends on what changes on the desktop (if nothing moves, nothing is copied and "timeout" occur). What exact problem do you have? – Simon Mourier Sep 23 '22 at 05:06
  • @SimonMourier I want to use this API as a screenshot interface, and only want to return success when the image changes, not including mouse movement. But the current phenomenon is that mouse movement will reduce the number of successful returns per second for this API. – yanrk Sep 23 '22 at 08:14
  • 1
    What you're doing is probably wrong due to a misunderstanding of how this API works. Try Microsoft official sample and you'll see it has zero performance problem unless proven otherwise https://github.com/microsoft/Windows-classic-samples/tree/main/Samples/DXGIDesktopDuplication. Difficult to help w/o any piece of reproducing code. https://stackoverflow.com/help/minimal-reproducible-example – Simon Mourier Sep 23 '22 at 08:43
  • It's not a bug, it's behavior by design, you are responsible to handle the updates in efficient way. – Roman R. Oct 02 '22 at 20:51
  • @RomanR. ok, I'll keep trying – yanrk Oct 11 '22 at 03:18
  • @SimonMourier ok, I'll keep trying – yanrk Oct 11 '22 at 03:19

0 Answers0