I’m on mac so i can’t run your code, but cinder provides its own flipping routines in cinder/ip/Flip.h. Perhaps you can try those just to rule out that it’s not some peccadillo of opencv’s?
Re-reading your post, you won’t be able to create opengl objects (specifically textures in this case) on a secondary thread without creating a shared context. There’s a few ways to go about syncing with the main thread for your opengl calls, so don’t take this method as gospel, but I’m pretty sure it’s a solution to the problem you’re seeing. Importantly this has no idea how the kinect library works internally so it’ll be up to you to make sure there’s no thread safety issues elsewhere, as well as things like writing directly into the frame’s color surface, etc.
Just written without compiling so there might be a few problems, but it should be ok. You won’t need to lock the mutex in your draw call anymore as all touching of mTextureColor now happens on the main thread.
it probably will because looking at it again it’s probably a safe assumption the Surface returned by frame.getColorSurface(); is reused internally by the kinect library. I tried to weasel my way out of responsibility for that but can’t put a thing past you Paul.
@okinp once you’ve confirmed that the secondary thread is indeed what’s causing your textures to show up black, i suggest you have a look at some more robust multithreaded opengl code like the FlickrTestMultithreaded sample that comes with cinder for how to proceed from there.