Reply from one of our graphics engineers: Thanks for the thorough bug report and analysis and suggested work-around!
For what it's worth, this portion of GLSurfaceView has been rewritten for a post-2.0 version of Android. The new version uses a single "wait()" loop for all the different reasons GLSurfaceView needs to wait, so the mPaused change will no longer be lost. On Sat, Nov 21, 2009 at 11:24 PM, [email protected] < [email protected]> wrote: > My OpenGL app animates only every now and then, so I decided to use > RENDERMODE_WHEN_DIRTY to save some battery life. However, I found that > when I go to Home Screen and return to my app, I often get a black > screen, and I see this in logcat: > > E/SurfaceComposerClient( 6055): using an invalid surface id=1, > identity=735 should be 738 > > This seems to be caused by this code in GLSurfaceView (1.6 here, but > 2.0 has same problem): > > > synchronized (this) { > ........ > if (mPaused) { > mEglHelper.finish(); > needStart = true; > } > while (needToWait()) { > wait(); > } > ....... > } > if (needStart) { > mEglHelper.start(); > ...... > > If I use RENDERMODE_WHEN_DIRTY, I will be stuck inside the wait() > call. When my app is paused/resumed, GLSurfaceView.{onPause,onResume} > will be called, by the change in mPaused will be lost. So when wait() > finally finishes, the mEglHelper.finish() and mEglHelper.start() lines > are not executed, and I end up drawing into the wrong surface. > > The work around is simple but a bit ugly: > > public MyView(....) { > super(....); > setRenderMode(GLSurfaceView.RENDERMODE_WHEN_DIRTY); > } > > public void onResume() { > super.onResume(); > setRenderMode(GLSurfaceView.RENDERMODE_WHEN_DIRTY); > requestRender(); > } > > public void onPause() { > setRenderMode(GLSurfaceView.RENDERMODE_CONTINUOUSLY); > android.os.SystemClock.sleep(60); > super.onPause(); > } > > The trick is to temporarily get the GLSurfaceView to run in > RENDERMODE_CONTINUOUSLY. I found the sleep(60) to be necessary to > avoid race conditions that somehow left me hanging inside the wait() > ---- but I am not sure if this is 100% scientific. > > Anyway, cheers, and save a few battery bars! > > P.S., I found this to be somewhat disconcerting ... as the longevity > of this bug shows not too many people are trying to use OpenGL to make > their UI faster -- and battery efficient. This probably means that > iPhone apps will continue to look-and-feel better than Android for > quite some time :-( > > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<android-developers%[email protected]> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
