Android SDL_APP_DIDENTERBACKGROUND gives no time for GL call |
Android SDL_APP_DIDENTERBACKGROUND gives no time for GL call |
Michael Labbe
Guest
|
Does disabling SDL_ANDROID_BLOCK_ON_PAUSE stop the context from being destroyed? Docs imply it does. I haven't gone there, myself.
Realistically even then, your GL calls are asynchronous and, by going into the background while pulling pixel data, you are tempting driver bugs to appear on various EGL driver implementations which may assume certain things about the graphics state while backgrounded. Android EGL implementations do not always do the right thing. I would consider having a recent copy of the texture in the gameplay thread before SDL_APP_DIDENTERBACKGROUND is ever called. On Mon, Nov 2, 2015 at 3:55 PM, Jonathan Dearborn wrote:
|
|||||||||||||
|
Android SDL_APP_DIDENTERBACKGROUND gives no time for GL call |
Jonny D
|
No, sadly SDL_ANDROID_BLOCK_ON_PAUSE=0 doesn't affect it. It's normal behavior for Android to invalidate the context, even for Java apps; I just don't have the chance to react.
Jonny D On Mon, Nov 2, 2015 at 8:21 PM, Michael Labbe wrote:
|
|||||||||||||||
|
Android SDL_APP_DIDENTERBACKGROUND gives no time for GL call |
Jonny D
|
Well, what I wanted to be done looks like it's already done... SDL_PushAppEvent() calls SDL_PushEvent(), which does immediately pass execution through the event filter callback. This seems to mean that at no point (in the native code, at least) does SDL get any chance to react before the GL context is gone.
My only thought at this point is from arbitrary search results, because I'm not very experienced in the Android API. Perhaps SDL's SDLSurface class could extend GLSurfaceView instead of SurfaceView and call setPreserveEGLContextOnPause(true). Not sure if that would totally mess up SDL's native EGL handling and it's hardware implementation dependent. Jonny D On Mon, Nov 2, 2015 at 10:56 PM, Jonathan Dearborn wrote:
|
|||||||||||||||||
|
Android SDL_APP_DIDENTERBACKGROUND gives no time for GL call |
Preet
Guest
|
On Mon, Nov 2, 2015 at 11:23 PM, Jonathan Dearborn wrote:
For GLSurfaceView, if the context isn't destroyed until you call onPause then you can probably call into a native function to save your texture. MyActivity { Â Â onPause() { super.onPause(); saveTexture(); glSurfaceView.onPause(); } } With SDL I'm not really sure. You have the ability to create your own Activity that derives from SDLActivity. Maybe something like the following would work: public class MyActivity extends SDLActivity { Â Â onPause() { saveTexture(); super.onPause(); } Â Â private void native saveTexture(); } You'd implement saveTexture() in your native code using JNI. I think you would need to surround the function with MakeCurrent(context...) and MakeCurrent(NULL...) to set and release the context for the thread that calls into saveTexture since I don't think it will be the thread that does the rendering. |
|||||||||||||
|