robmikh / Win32CaptureSample

A simple sample using the Windows.Graphics.Capture APIs in a Win32 application.
MIT License
318 stars 89 forks source link

Desktop Duplication capture behavior change in 24H2 #83

Open artths opened 1 month ago

artths commented 1 month ago

I don't know if this is the right place for a report about the Desktop Duplication API, but I think the change might be related to the implementation of dirty regions API in WGC.

Given: a window that is disabled topmost overlay, with flags WS_EX_TOOLWINDOW | WS_EX_NOACTIVATE | WS_EX_TOPMOST | WS_EX_LAYERED | WS_EX_TRANSPARENT. Additionally, the WDA_EXCLUDEFROMCAPTURE flag is set to exclude it from capture.

The window is displayed on the same monitor as the captured content.

Behavior on 23H2: AcquireNextFrame returns only when the content under the window has been updated.

Behavior on 24H2: AcquireNextFrame returns when the content under the window is updated and when this window is updated as well, even though the window should remain "invisible" for capture because of the WDA_EXCLUDEFROMCAPTURE flag (window content still can't be captured).

This window displays some screen captured content, so when AcquireNextFrame returns when the same window is updated, it causes a series of false updates.

robmikh commented 1 month ago

Thanks for reporting this, but I'm unable to reproduce the behavior you're talking about on 23H2. I am seeing constant dirty rects that cover content from a window that has been excluded.

What build are you running specifically? In Settings -> System -> About, there should be a "Copy" button under 'Windows specifications".

artths commented 1 month ago

Thank you for your response. Unfortunately, I no longer have 23H2, as I had to upgrade to 24H2 to fix a software. My OS build is currently 26100.2033.

It’s surprising that you're experiencing the same issue on 23H2. As far as I know, the behavior of the Desktop Duplication API (DDA) has not changed since Windows 10 for any of my users and remained as I described for 23H2. However, it’s possible that this might be related to some new information I’ve uncovered. On 24H2, the behavior of the DDA changes significantly depending on whether Multiplane Overlay (MPO) support is present. For instance, I have a 144Hz primary monitor and a 60Hz secondary monitor. Dxdiag reports that the secondary monitor has MPO support, while the primary does not. Both monitors are connected to an Nvidia 3090 (driver version 565.90). With this configuration, the behavior of the DDA on the primary monitor matches what I described in my original message for 24H2. However, if I disconnect the secondary monitor, the primary monitor starts having MPO support (after reconnecting). With this setup, the behavior of the DDA reverts to what I described for 23H2.

I can’t say for sure if the primary monitor had MPO support when I was on 23H2, as I didn’t pay much attention to it then. But I suspect it was the same, with the key difference being that now the DDA seems dependent on MPO support. This may be related to driver behavior due to the transition to WDDM 3.2, though that’s just a guess.

I would greatly appreciate any insights you might have on this. Thank you!