Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Race condition in "show + capture camera" #36
Some excellent research by Petros Douvantzis determined that there is a race in the texture handling in "show + capture camera". The source of the problem is the use of a shared EGL context -- the camera frames are converted to an "external" texture in one context, but rendered from another.
For correct behavior, the application code must ensure mutually exclusive access during the texture update, and needs to issue GL commands that effectively provide memory barriers. On the producer side,
These operations will potentially stall the involved threads, reducing throughput. It's better, and simpler, to use a single EGLContext, and call
The other Activities in Grafika use SurfaceView and a single context, and are not affected by this issue.
referenced this issue
Nov 2, 2016
Sorry to dig this out of the crypt but I was hoping for some clarification about restricting CameraCaptureActivity to use a single EGLContext.
From what I can tell, it appears that the SurfaceTexture passed to the camera is already bound to the same rendering context as the GLSurfaceView, and that
In the original problem statement, you identified the issue as one where the camera is converting frames to an external texture on one context but then rendering them from another - can you elaborate on this a bit? From what I can see in the sample, the camera is sending its image stream to the SurfaceTexture presumably from another thread, but the actual create/bind dance to the external texture all happens within the GLSurfaceView's rendering thread
The texture is shared between two EGL contexts -- written by the camera, read by the video encoder. The GLSurfaceView side is fine by itself. Once you start recording, TextureMovieEncoder creates a shared EGL config, and it's the rendering from that thread that causes the trouble.