Enabling including secondary windows causes dirty region to be entire frame

[amirrosi]

On Windows 26100, rendering an app window, enabling the "include secondary windows" toggle causes the dirty region visualizer to show a red rectangle on the entire captured frame.
This suggest that the reporting only the changed regions doesn't work when enabling capturing of secondary windows.

[robmikh]

This is a known issue with the secondary window feature. It should still only provide a frame if something changes, but the dirty region right now is the entire frame. I'm working on a fix for tighter dirty regions when secondary windows are enabled.

[kevinmershon]

@robmikh Did this ever get resolved, and if so, for which build of Windows?

Additionally, since apparently DX11 dirty regions were only added in build 26100 is there a way to access this information on earlier builds or with a non-DX11 API?

[robmikh]

This hasn't been addressed yet. Before build 26100, your best bet is the Desktop Duplication API.

[kevinmershon]

This hasn't been addressed yet. Before build 26100, your best bet is the Desktop Duplication API.

Thanks for the quick reply. Unfortunately I am specifically working with window-level capture not full-desktop, so my understanding is the Desktop Duplication API is not a fit

[robmikh]

Ah yeah, then WGC is still your best bet. If you're only after the dirty region information, a stop gap could be to use a compute shader to determine a naive dirty region. This is what I've done in the past before we added the dirty regions API.

[kevinmershon]

Ah yeah, then WGC is still your best bet. If you're only after the dirty region information, a stop gap could be to use a compute shader to determine a naive dirty region. This is what I've done in the past before we added the dirty regions API.

Yep I'm just after the dirty region information. I will definitely look into doing that. But if you have any pointers on how to get started that would be super appreciated.

[robmikh]

Here's an older project that used this technique:

https://github.com/robmikh/CaptureGifEncoder/blob/master/CaptureGifEncoder/TextureDiff.hlsl

Although it's not set up optimally as written. I would use the maximum number of threads in just one dimension (e.g. [numthreads(64, 1, 1)]), and compute the texel coordinates from the single ID.