Multiple screen captures in a loop cause explorer.exe and native Windows app to lag? about windows.ui.composition-win32-samples HOT 11 OPEN

@robmikh
Ok, I'm almost certain what you said is indeed the issue.
Did a loop that's only doing -

                        GraphicsCaptureItem item = CaptureHelper.CreateItemForWindow(client.WindowHandler);

Every 100ms to speed up the process.

After a few minutes, my Windows Start menu is completely bugged, sometimes works, and sometimes takes 15 seconds to open.
The calculator app also.

Closing my App doesn't fix the issue as I mentioned before, a restart of the PC is required.
Maybe restarting explorer.exe would do the trick? I'll test .

edit -
Restarting explorer.exe also works.

from windows.ui.composition-win32-samples.

@robmikh
Ya, ran it for a few minutes and my explorer died completely.

from windows.ui.composition-win32-samples.

Not sure yet, I'll have to debug it on Monday.

from windows.ui.composition-win32-samples.

The GraphicsCaptureItems are backed by shell objects, it's conceivable that there's an issue that has down stream effects on explorer. But I haven't seen this reported.

It would be interesting to know whether keeping the GraphicsCaptureItems around instead of creating new ones mitigates the issue at all.

I'll see if I can repro when I get some time.

from windows.ui.composition-win32-samples.

I'll try to implement your suggestion, creating a single instance of GraphicsCaptureItems per window and keeping those in memory instead of recreating an item on every iteration.

Kind of hard to debug as this issue might take hours to reproduce, can't pinpoint it yet...
Will try reducing the interval time to speed-up the process guessing that's what causing the issue.
If you get the chance to repro and confirm I'd appreciate it if you can let me know.

Thanks

from windows.ui.composition-win32-samples.

@robmikh
Just an update, I've tested it during the night with 5 instances of GraphicsCaptureItem without recreating them. (using the screenshot service I shared above)

It's not as bad but the issue still occurs.
Start Menu/Calculator lags, etc.

So basically I can't see a workaround that lets me use this API without telling my users they need to restart their explorer.exe every 24h ><"

Please let me know if you can think of a hotfix/workaround that I might be able to upload until a fix is provided.
Thanks

from windows.ui.composition-win32-samples.

I think I'm able to repro, but just to be sure can you try running this code and see if it reproduces your issue after a few minutes? https://github.com/robmikh/manyitemstest

You'll need to use CTRL+C to exit it.

from windows.ui.composition-win32-samples.

Does this also explain why the last test I did (5 instances without recreating) also caused explorer.exe to lag after a while?

from windows.ui.composition-win32-samples.

Hey Rob,
Can I ask for an update and if you can provide an ETA by any chance?

So that I can plan ahead and understand if I can wait for a fix or if I have to develop a fix with the old capture approach using user32.dll as my app is currently live and customers Explorer is dying lol

from windows.ui.composition-win32-samples.

Sorry but I have no ETA at this time. You may want to roll back if the issue is pressing.

from windows.ui.composition-win32-samples.

Got it, nothing to roll back to, the app was built around this API.
Would appreciate an update once there is one so I can forward it to my customers, thanks.

from windows.ui.composition-win32-samples.