WGC captures windows constantly instead of when content is changed

[amirrosi]

Hi,

First, I would like to thank you for the effort on WGC and this sample. They are a great help for building a screen and window content capturing app.

Now, I examined the demo to validate performance and saw that on my system (see below) it's quite heavy on performance - the DWM process appears to have high GPU utilization which can reach 50-60% on even simple apps such as Excel.
So, I checked capture rate (counting calls to OnFrameArrived) and found that it's very high - 120 frames per second.
This is reasonable since the laptop display freq is 120hz. However, the rate is too high for my needs and could be greatly reduced.
Also, many apps (such as those in Office suite) doesn't change very frequently. So, updating only dirty regions could be a benefit to performance.

So, it seems that the MinUpdateInterval and DirtyRegionMode features could really serve well here.
However, I was disappointed to find these features disabled in the sample. Checking the code seems to imply that they are not supported on my system.
However, I just recently updated to the most recent Windows 23H2 update (KB5041587).
Also, the Windows SDK which is used is 26100 which should be as required.

Also, could you explain why WGC differ in performance (in terms of DWM's GPU utilization) for different apps, with the same window size and resolution? For example, I found that Excel and Notepad++ are pretty heavy on the GPU while other apps such as File Explorer, Visual Studio and more are much less heavy.

Here's my system info. Notice it has an Intel integrated Arc GPU of the Intel's 155H chip.

[robmikh]

I'm glad you've found the sample useful!

Sounds like there's a bug, we shouldn't send new frames if there are no new updates.

As for the features you've listed, they're available on build 26100, which you aren't running. I don't think that build is yet available other than on new machines. The SDK doesn't contain the implementation, just headers and metadata. The implementation comes from the operating system.

[amirrosi]

Thanks for the prompt reply.
Just noticed that 26100 is actually a Windows preview build which isn't automatically available to non-Insider users.
I'll try install this preview version and let you know:

1. Whether the features are enabled.
2. Whether capturing rate is per app content update (as should be) or fixed to some constant (bug).
   It would be great to have capture per app update as it should really reduce GPU utilization.

[amirrosi]

After an update to Windows 24H2 26100 build it is confirmed:

1. The features of MinUpdateInterval and Dirty Region mode exist and work well.
2. Capturing is done only when an app content is changed. So, there is a bug in 23H2 which is solved in 24H2.

Should the bug be solved for 23H2 or will it remain as a known issue?
Or perhaps is there a patch that can be installed to fix this on 23H2?

[robmikh]

Thanks for checking if this behavior repros on 26100!

I'll have to do an investigation when I'm back in the office. We did a sizable change in the compositor to bring dirty region support to WGC, but maybe there's a smaller fix I can push out for 23H2.

[amirrosi]

Any luck with reproducing/finding the bug on 23H2?

Trying to figure this out as I guess there are many apps that use WGC and it can't be that they all suffer from such performance issues.
So, I checked Chromium capture mechanism, implemented in WebRTC which uses WGC. (see here)
Apps such as Google Meet that can share an app window don't really have such performance issues as described above - sharing an app really doesn't have any impact on GPU until the app window is changed and then DWM GPU utilization spikes (tested this on the same Windows 23H2 version as the Win32CaptureSample was tested, verified GPU with Task Manager).

However, the code doesn't appear to handle WGC in a certain way that avoid the issue.
Is it possible that a different configuration/setup of WGC can solve the issue? Initializing from a different thread? Handling retrieved textures differently perhaps?

[robmikh]

I haven't had a chance to investigate this, I'll provide an update when there's something to share.

It's unlikely that a WGC configuration changes this behavior, but it could be that your hardware setup does (e.g. monitor configuration). WGC is just another render target in the compositor, and is effected by other conditions in the system compositor.

[artths]

This bug has existed for years since the winrt API release (1903). I can confirm that this is finally fixed in 24H2, it would be nice to have it in older versions as well.