FrameArrived rate on RDP sessions

[sairav544]

I’ve been trying to use the WGC capturer inside RDP sessions. I’ve found that the FrameArrived rate is around 40–50 fps. I’m using the DWMFRAMEINTERVAL = 15 registry trick, and it seems that the process window manages to run at a consistent 60 fps. I’ve also been using the same tool mentioned in this issue: #45

The values I’m getting are the following:

• For CaptureAdHocTest.exe monitor-info

• For CaptureAdHocTest.exe fullscreen-rate -fw

So, everything suggests that it should be able to capture at 60 fps, but it doesn’t. I’m not sure what exactly determines the rate of the FrameArrived callback. I believe it has something to do with RDP using the Remote Display Adapter, but right now I’m pretty lost.

[robmikh]

What build of Windows are you on? What resolution are you running at?

Given that CaptureAdHocTest is capable of matching the update interval you configured, the problem is probably in how you set up the capture and process the frames. Some things to consider:

• If you starve the DWM of frames (keeping references to the Direct3D11CaptureFrame objects), the DWM will be forced to skip frames since it has nothing to draw into.
• If you create the frame pool with Create, you need to make sure that you are pumping messages and not holding up the message pump. If you create the frame pool with CreateFreeThreaded, any blocking you do on the callback will block the capture API to enqueue new frames.
• When you close a Direct3D11CaptureFrame, we signal a fence internally. This means that if you queue up a bunch of GPU work and then call Close/Dispose, you'll have to wait longer until that frame is available to the DWM. I would recommend doing the minimal amount of work (e.g. making a copy or only running the first part of your pipeline) and then returning the frame to the pool before further processing.

[sairav544]

Hi! Thanks for the suggestions. I checked the time spent in the callback/when the frame gets dropped, and I saw that the time was too small to be the problem. Anyway, I found that the issue was in SetMinUpdateInterval. I wasn’t using this method before (and when I did use it, I set its value to 16). Then I tried setting the value to less than 14, and now it reaches 60 fps.

The question I still have is: why do values like 16 and 15 cause a capture rate of around ~35 and ~45 fps respectively? I understand that since it’s a minimum time, it means “at least 16 ms,” but that it could take longer. Maybe it has something to do with when exactly the compositor checks whether the minimum interval has passed?

Im on windows version 26200.7171 and resolution 1920x1080.