-
Notifications
You must be signed in to change notification settings - Fork 185
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Does Direct3D11CaptureFramePool actually require a DispatcherQueue? #59
Comments
I ask because we're hearing infrequent reports of shutdown hangs, and I'm wondering if this is the reason. |
When the frame pool is created with Regardless, the most important part of the I know that you mentioned hearing infrequent reports of this, but if you get a consistent repro or a memory dump when this happens I can take a look. |
Additionally, I would recommend creating a DispatcherQueue for your thread by calling Or you can forgo the dispatcher requirement all together and use |
I can let a dispatcher queue live for the life of the thread. For simplicity, we do all WGC things on our render thread since we have that's where our D3D11 renderer operates. I suppose this would be advised?
We have a separate message pump that lives on the main thread that is implicit to Qt. Hopefully these aren't fighting each other, but my Win32/COM knowledge isn't that strong. The render thread pump was added recently just to support WGC. I can find out if we have any memory dumps. |
That sounds reasonable to me, and having the two different pumps on two different threads should be ok. The only thing I would add is that I would add a call to |
Thanks, you reminded me I didn't set up the winrt apartment either. I also noticed we were keeping WGC objects alive across render threads (we kill and recreate the thread in some situations), so I added a fix to destroy on thread stop and recreate on thread start. Hopefully everything is robust and stable now. |
I have a couple of memory dumps from the shutdown freezes we experienced, these are full heap dumps so I don't want to link them publicly. The WGC thread was stuck in a COM call to the "Capture Service" process. Debugging the service showed no stuck threads, almost like it wasn't aware of the COM call.
|
Thanks, @notr1ch! It would be interesting to know if this still happens after initializing COM on the thread. If the proxy stub is blocked and the service is unaware of it, it might be an initialization issue. If it persists, we can maybe talk through another channel about looking at the dump if you feel comfortable. A dump of the capture service would be interesting as well. |
Closing this issue. If you still see this after properly initializing COM, please let us know. |
We added the DispatchQueue and RoInitialize call, and we haven't seen the problem since, so we're probably good now. I also added code to disable the yellow border recently, but I had to switch our thread from STA to MTA to get rid of the assert from blocking on the RequestAccessAsync result in-place. Do you think this is fine? |
Despite the comment saying a DispatcherQueue is required, I don't instantiate one in my application, and window capture seems to work fine. What are the consequences of not doing this?
The text was updated successfully, but these errors were encountered: