The maximum frame capture is 60 per second is limitation

[JustinKJChen]

Measure latency per frame capture, the latency is 15ms-17ms.

The latency is 15ms-17ms per frame capture, is this performance for frame capture?

The capture device is nVidia RTX4090.

[JustinKJChen]

The display refresh rate is 240 Hz.
But I find the almost latency is 15-17ms per frame capture.
This limitation is exceptional?

[robmikh]

Could you share some more details?
What build of Windows are you running? Are you capturing a window or the whole screen? Are you capturing a full screen game that is rendering at >60 fps?

[JustinKJChen]

Could you share some more details? What build of Windows are you running? Are you capturing a window or the whole screen? Are you capturing a full screen game that is rendering at >60 fps?

Windows build is 10.0.26100
The game launch with fullscreen, nVidia DDS generate Display2. I set capture whole screen in Display2.
The game is rendering during 220-240 fps

[Esvandiary]

We've been seeing the same with WGC on 24H2 (26100) with some users. We've seen it with our recorder but the same CaptureSample binary does full frame rate on pre-24H2 but seems to be capped to 60fps on 24H2.

[robmikh]

Does this improve if you set the MinUpdateInterval property to something non-zero? Like 1 millisecond?

namespace winrt
{
    using Windows::Foundation::Metadata;
    using Windows::Graphics::Capture;
}

if (winrt::ApiInformation::IsPropertyPresent(winrt::name_of<winrt::GraphicsCaptureSession>(), L"MinUpdateInterval"))
{
    session.MinUpdateInterval(std::chrono::milliseconds(1));
}

[Esvandiary]

@robmikh Yes it does! Thanks for the tip, we can use this to fix high-framerate capture in our recorder for now.

If I could ask for a bit of info on the implementation of MinUpdateInterval, if possible - is it "once elapsed we'll deliver the next frame once it's provided to us in the future" or "once elapsed, we'll immediately deliver the last frame we received if we have one that wasn't delivered yet"?
In other words if we set MinUpdateInterval to 10ms, will we typically see 100fps (assuming >=100fps frame rate of the target content) or will we be undershooting a bit due to waiting for the next frame after the interval elapses?
I can appreciate this is something that could change in future so you might not want to commit to a specific behaviour, that's fine if so. We can continue using our own frame rate limiting mechanisms (and will do on pre-26100), but obviously this will be more efficient if we can make use of it!

[robmikh]

Good to know! I think I know what's going on then.

As for how MinUpdateInterval works, we are tracking dirty regions in the compositor. When the compositor goes to render a frame, it will check if the interval has elapsed and draw if there are any accumulated dirties. It's implemented this way to reduce the rendering done in the system compositor.

Ideally this means you should get something that matches the specified interval, assuming the content is constantly changing.

[Esvandiary]

Thanks for the explanation! That sounds like we will need to guard against frame rate undershooting, which is fine (we'll just specify a MinUpdateInterval of "a bit" shorter than what would be required for our nominal frame rate).
Very cool to see this feature get added BTW - previously we've essentially been having to just drop frames if the content's frame rate is way higher than our nominal capture frame rate, which felt wasteful.

[artths]

Possibly related to default MinUpdateInterval value bug #82

[reflectronic]

Is this behavior by-design, or should we expect the workaround to be unnecessary in the future?

[robmikh]

The intended default will be 60hz. The issue is that if you set the MinUpdateInterval to 0, it won't be properly honored unless you set it to something non-zero first. That has been fixed, and hopefully that should be turned on in the next month or so.