Frames updates not working for certain windows that are completly obscured by a window on top with exclude capture.

[mikeh926]

Hi,
Frame updates (OnFrameArrived) is not being triggered in some circumstances, depending on the application you are running and their window positions.

This is a scenario we are hitting with our screen magnifier, but you can replicate it using just the sample capture application.

When you have a window with exclude capture set, the capture API will return all other windows as if it didn't exist. this seem to work correctly. However, for some of these windows, if rendering occurs and the window is completely covered by the excluded capture window, no frame updates occur. (OnFrameArrived does not get called).

The scenario where this is failing includes Microsoft Word, and Microsoft Edge, where you might be editing with a flashing cursor or a dynamically changing website. Microsoft Word is more difficult to replicate because Word stops flashing when it looses focus, but you can replicate in Edge with a simple website with continually updating content.

This is impacting our screen magnifier, because it has an on-top window that is excluded from capture. Our on-top window also has WS_EX_TRANSPARENT set so the focus can remain in the app. The problem then manifests itself with general app usage instead of just backgraound updates.

Steps to replicate:

Use latest Windows 11. I have 25H2 26200.7623 with lastest windows updates installed.
Open Microsoft Edge and go to https://digitalclock.org/ which has a ticking clock (or any website that has continual updates).
Resize the Edge windows so it is failry small, not touching the side of the desktop and you can see the continual screen updates.
Run the win32capturesample.
Choose a display.
Turn on "exclude this window".
Move/Resize the capture sample app so that it completely covers up the Edge Windows with the ticking clock.
Observe that capture updates stop.

You can also replicate if you maximize both Edge and win32capturesample.

This used to work fine until recently. We believe the problem started after a recent windows update, although we don't yet know which specific update has introduced the issue.

We also have a 24H2 machine with the same problem, but again you have to have the latest set of windows updates for it to go wrong.

Note that if you have other applications running that are also doing continual screen updates, even if it's just a system tray icon, this may prevent you from replicating. Ideally test on a clean install of Windows 11.

The problem affects Microsoft Edge and Microsoft Office apps (and probably many others). However, it does not seem to affect TaskManager or the Windows 11 clock app which also update continually.

Best Regards,
Mike.

[robmikh]

Thanks for reporting this!

For Edge specifically, this is something that Edge is doing and isn't controlled by the operating system. Edge has some custom logic to determine if the window is occluded and to stop drawing in that case. You can defeat it if you use the WS_EX_NOREDIRECTIONBITMAP and WS_EX_TRANSPARENT window styles. Then Edge will draw normally when occluded by the window. I gave this a try with a simple window that uses the above window styles, marks itself as excluded from capture, and then runs a capture which draws to a swap chain hosted by DComp to the window.

I'll need to spend more time to figure out what's going on with Word, however. I wasn't able to repro but I didn't try for very long.

[mikeh926]

Hi,
Thanks for the information. It wouldn't be the first time we have had issues where an application changes behaviour because it thinks it's covered up.
I need to do some more testing with Word. I am also having problems with the damage region for ReportAndRender mode not matching frame updates (see my other recent issue report). The issues get worse when I call SetCaptureDelay() with values > 1. It's also exacerbated by having an on-top excluded window. It feels like I am loosing frames somewhere but it's unclear if it's my bug or not.
What I can say is that it was all working nicely pre-the release of 25H2 and my code hasn't changed! Unlike the sample app, I am also passing captured frames between differnet instances of direct3d11 devices using shared surfaces with a keyed mutex. Maybe this isn't working as expected.
When my magnifer is running, I can put a break point on OnFrameArrived, type something in word and the breakpoint doesn't fire. I believe Word is rendering regardless of any on-top window because I am hooking the entire directcomposition API to build an off screen model, and that gets updated because Word is commiting changes to it's dcomposition tree, but I just don't get a captured frame to match. Is the DWM just not doing anything because it doesn't think Words composition objects are visible?

I will try changing my output window to use WS_EX_NOREDIRECTIONBITMAP with a Dcomp hosted swapchain and see if that helps with Edge. (Chrome also has the same problem).
Thanks,
Mike.

[mikeh926]

I have modified your sample to include an optional full screen overlay window that is on top of the monitor you are capturing. This is WS_EX_LAYERED and WS_EX_TRANPARENT, so it allows through key and mouse input. Apart from that the extra window does nothing, I am not drawing anything to it.

My modified sample code is here: https://github.com/mikeh926/Win32CaptureSample

Using this sample you can replicate the dropped frames issue with Word. I also found that Putty (terminal app) has the same problem.

You need 2 monitors. Run Word on your second monitor, run the sample, turn on "create overlay window" and capture the second monitor. Set "min capture period" to 200ms.
Although you can't see the second monitor (the overlay window has nothing painted in it) it is transparent so will let through mouse and keyboard events. Use the capture output window on monitor 1 to see what you are doing.
I you click on word and start typing, you will note pauses in the capture update. Sometimes it's delayed (more than 200ms), others you don't get the update at all.

I think the issue only occurs if you have set a min capture period. With min capture = 0 I can't replicate, and the Edge window also update correctly.

Also, set the rendering mode to "ReportAndRender" and Min Capture to non zero, Try dragging windows around. This will leave trails of incorrect updates in the window. I have modified ReportAndRender mode to only copy and present the reported damaged areas whilst maintaining the non-damaged areas from the previous frame. (Present1() should do this).

[robmikh]

Thanks for the modified sample, that helps a ton! I'm able to consistently repro now, I was missing the MinUpdateInterval connection.

[mikeh926]

I have also found that if you don't call MinUpdateInterval() but instead manually control the capture rate by delaying the release captured frames so that the frame pool becomes exhausted, you get the same symptoms.