DirectX threading issue (DirectX/Opengl interop) - Windows Desktop Duplication API vs2015

I’m working on implementing the windows DesktopDuplication API for screen capture on windows (8+), which should be much faster than using the older GDI method, a quick test with the example project appears to have virtually 0 overhead.

It requires a having an Direct3D device and a device context. I’ve set these up in separate thread. Now I need to access to the DirectX texture in the oF opengl thread. For this I’m trying to use the DirectX/OpenGL interop functions, I’ve followed the method in this example

I’ve tried accessing both the backbuffer texture as well as the texture I’m copying the desktop to, But I’m getting this error

D3D11 CORRUPTION: ID3D11DeviceContext::UpdateSubresource: Two threads were found to be executing functions associated with the same Device[Context] at the same time. This will cause corruption of memory. Appropriate thread synchronization needs to occur external to the Direct3D API (or through the ID3D10Multithread interface). 7580 and 9480 are the implicated thread ids. [ MISCELLANEOUS CORRUPTION #28: CORRUPTED_MULTITHREADING]

Which suggests I’m probably not using the interop correctly. Here’s a link to the project

Any help/suggestions would be much appreciated, once it’s working I plan on creating a oF addon to share.


Didn’t have much time to look at your project but if it were up to me I’d try to do the following to avoid threading issues:

  • Create three shared textures (A, B C) and three pointers glTexture, dxTexture and swapTexture
  • openGl draw the glTexture
  • directX do the duplication api to the dxTexture (or if it’s too complicated, you manually copy the (directX) texture you get from directX to a shared texture)
  • When directX is done rendering a frame, lock a shared lock, set a isFrameNew to true (I guess that could be useful) and swap the pointers (dxTexture; swapTexture)
  • When openGl is about to draw, lock the shared lock, check if the Frame is new, and if so, swap the pointers (glTexture and swapTexture)

This might not be the most memory savy but it does the job of preventing multiple access of the same ressource and locking for too long a shared ressource (I guess you could do the same without the swap texture; but you’d have to wait for one thread to be done to keep going on the other which would most likely end up in performance hit)