1

I am continuing work that I referenced here and have hit a few snags. I have a VirtualDisplay that has a Surface that the frames are written to and then I use that same surface as input for a MediaCodec so that the frames from the VirtualDisplay are encoded. This is all occurring in some Threads that are running in an Android Service NOT in an Activity.

I now want to add an intermediary Surface into the chain so that the progress will go VirtualDisplay -> write to SurfaceA -> some logic/features -> write to SurfaceB -> encode SurfaceB

I have created, after much struggle, SurfaceA using just straight OpenGL and EGL calls, not using GLSurfaceView. I'm using this as an example of how I should be writing from SurfaceA to SurfaceB. From my understanding I just need two EGLSurfaces in a single EGLContext.

From my understanding, the GL context can be lost at any time and I may need to recreate my OpenGL texture (and maybe EGLSurfaces too?). This is usually handled via GLSurfaceView but since I am not using one, is there an easy way to know when the context is lost? Should I just use a GLSurfaceView even though none of my work involves a View or is visible to the user? How do you call onPause and onResume for a GLSurfaceView if there is no Activity?

Thanks for the help.

Community
  • 1
  • 1
EncodedNybble
  • 265
  • 2
  • 11

1 Answers1

0

You want to use a SurfaceTexture (a/k/a GLConsumer), which converts frames arriving on the Surface into GLES textures. It has no View component.

GLSurfaceView is the worst possible thing to use, as it will create and destroy its EGL context when the Activity pauses and resumes. (EGL contexts do not get lost -- they go away when they're destroyed. Don't use GLSurfaceView if you care about the lifespan of your context.)

Various examples of SurfaceTexture use can be found in Grafika. You can use one EGL context with two EGL surfaces, or two separate EGL contexts with shared state. The former is probably easier.

See also the graphics architecture document.

fadden
  • 51,356
  • 5
  • 116
  • 166
  • Right. I am using a `SurfaceTexture` right now that has no `View` component. I have everything working with so far with no problems. I believe OpenGL contexts can be lost on power down/sleep/etc. Question was more of "Are OpenGL contexts loss and how to detect when they are?" – EncodedNybble Oct 04 '15 at 06:28
  • The AOSP code should not throw them away. The GLES driver shouldn't be able to tell the difference between a foreground app and a background app, so I would expect the foreground app to fail if the driver did this. Do you have a reproducible test case showing GLES contexts being lost on power down / sleep? I would expect any GLES operation to result in a "bad context" error from the driver. – fadden Oct 04 '15 at 15:54
  • I don't actively see context loss in the code that I have, I just remember dealing with OpenGL context loss when working on previous Android projects (which were games). I also saw a bunch of context loss related questions on SO, so I thought I'd ask. My question was trying to get in front of potential issues. I currently check for EGL failure coded (one of which is loss of context) when calling swapBuffers and if that fails, grabbing the EGL error and doing context loss behavior there if the error code was context loss. – EncodedNybble Oct 05 '15 at 20:10
  • If it is a non issue, then I can just close/delete this question. Thanks for the input. – EncodedNybble Oct 05 '15 at 20:11