How to prevent the OGL context being trashed on pause


#1

When you get your app pause/stop etc to work, and also for rotation, the OpenGLContext is normally trashed by Android. This is bogus because, even after having my code reinitialise all the geometry, textures etc, it took several seconds after a `onResume’ to become responsive. Basically, this is likely to be the case whenever you’re storing VBO/VAO over on the OGL side, because you have to set them all up again!

so, if you’re happy to base >= API 11, do this:

[code] OpenGLView (Context context)
{
super (context);
setEGLContextClientVersion (2);
setRenderer (this);
setRenderMode (RENDERMODE_WHEN_DIRTY);

        // dont trash the OpenGL context all the time
        setPreserveEGLContextOnPause(true);  // API 11
    }[/code]

How to prevent android OpenGL context being trashed/rebuilt by rotate
#2

Hmm. That’s annoying…

API 11 might be an ok minimum these days - isn’t it the case that earlier versions don’t support GL shaders, so can’t run this code anyway?

Or… my java is a bit rusty, but isn’t there a way to invoke a method via introspection, so that this could be called on API 11 and above, but would still compile without warning for earlier ones?


#3

yes, there must be a way to call this conditionally, so that it compiles with an older API.

I’ve been using OGL shaders on API 10. The problem is that it just too slow to re-create everything when the OGL context is renewed. When an app is paused then resumed, the user doesn’t expect it to freeze up for 5 seconds.

A couple of things;

firstly, even with this call in place, Android can still trash the OGL context on pause. However, this doesn’t happen in practice (much) if your app was the main focus when paused. In the rare cases if it does trash it, well, it’ll just have to take 5 seconds to come back. So my point here is that you’re still obliged to write your code to cope with such a case.

secondly, without this call, modern up-to-date devices suffer unnecessary delay. I don’t want this for people with new kit, so if it means making API 11 the minimum, so be it.

Of course, both would be better.


#4

You should be able to wrap it in a test like this:

if (Build.VERSION.SDK_INT >= 11) {
...
}