Hm.
This would be true (perhaps; opencv doesn’t randomly overwrite data buffers either afaik) only if I was using openCV; I’m not. I’m using libfreenect and I’m using a custom driver that I’ve written myself to read the kinect data.
The c driver carefully triple buffers the video frames to handle the situation where:
- You have a new pixel buffer pointer waiting to pass to the texture.
and
- You’re busy using the old pixel buffer on a current texture.
and
- In that small interval frames are rendered by a separate thread.
(it’s written this way specifically so that way the rendering can be done in a separate thread safely).
Accessing the new frame of data iterates through the buffer set such that you never encounter the situation where the buffer in (2) is being written to in the brief window between when (1) is accessed and (1) is passed into the texture. The third unused buffer is used in this case.
For this to be an issue, the updateTextureTask() call on my texture would have to be invoke simultaneously in multiple threads at the same time, and a separate rendering thread would have to be rendering frames between the lines:
(rgb, depth) = self.__vision.next()
rgb = long(rgb)
self.setRamMipmapPointerFromInt(rgb, 0, self.__vision.width * self.__vision.height * 3) To be fair I suppose that is a possibility; the SDL renderer that I wrote to check the data stream isn’t running multiple threads updating at the same time and rendering at the same time, but … I’d be surprised if panda is doing this? Surely not?