today was battle time again with the mmLock and OGL. In my last OGL effort, i eventually gave up and removed the mmLock from OpenGLContext::CachedImage::renderFrame. Yes, very naughty i know. However, it didnt seem to cause any problems with 3D vs 2D conflicts in my app (luck i think).
The problem with this lock is that under Android, when the app is suspended, the lock remains in place and it hangs up never to come back. eventually the Android task manager will kill it. This happens when you hit the home key or switch tasks. you know how Android tries to keep some sort of zombie memory image for some odd reason. then it switches back to it. This is bogus anyhow because your OGL context is trashed regardless and you have to reload assets which takes the same time as restarting your app from cold. Very annoying.
Anyway, apparently it can crash sometimes. that lock i thought. But after putting it back in, the occasional crash is still there annoyingly. But i thought i’d have a go at keeping the lock; I tried everywhere in vain to remove the lock on ‘suspendApp’, in destructors and just about everywhere inside the OGL context class.
no luck. what i think it happening is that Android just pulls the process out of state at the drop of a hat, putting the memory image in its back pocket. Then it somehow expects it all to start working again later.
the other thing is had is that i had to put back my fix in `initialiseOnThead’.
[code] void initialiseOnThread()
{
associatedObjectNames.clear();
associatedObjects.clear();
// drop any previous data if we're called again (eg Android)
cachedImageFrameBuffer.release(); // <- FIX
...
[/code]
I see the “fix” was moved to `shudownOnThread’ but AFAIK that doesnt actually get called in a pause/resume scenario, because Android is doing naughty things with the process.