RE : Re: RE : [android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently

2010-04-08 Thread seb boyart
Here's a crashlog.
It happened on n1 after a rotation.
Looks like the swap function is called with a wrong arg.
04/08/2010 09:30:00 [DEBUG] EglHelperSLWP(465) start()
04/08/2010 09:30:00 [DEBUG] EglHelperSLWP(465) getting new EGL
04/08/2010 09:30:00 [DEBUG] EglHelperSLWP(465) getting new display
04/08/2010 09:30:00 [DEBUG] EglHelperSLWP(465) getting new config
04/08/2010 09:30:00 [DEBUG] EglHelperSLWP(465) creating new context
04/08/2010 09:30:01 [WARNING] SLWP(465) Background Load GLError: 1281
04/08/2010 09:30:02 [DEBUG] EglHelperSLWP(465) start()
04/08/2010 09:30:02 [DEBUG] EglHelperSLWP(465) getting new EGL
04/08/2010 09:30:02 [DEBUG] EglHelperSLWP(465) getting new display
04/08/2010 09:30:02 [DEBUG] EglHelperSLWP(465) getting new config
04/08/2010 09:30:02 [DEBUG] EglHelperSLWP(465) creating new context
04/08/2010 09:30:03 [DEBUG] EglHelperSLWP(465) start()
04/08/2010 09:30:03 [DEBUG] EglHelperSLWP(465) reusing EGL
04/08/2010 09:30:03 [DEBUG] EglHelperSLWP(465) reusing display
04/08/2010 09:30:03 [DEBUG] EglHelperSLWP(465) reusing config
04/08/2010 09:30:03 [DEBUG] EglHelperSLWP(465) reusing context
04/08/2010 09:30:03 [WARNING] SLWP(465) Background Load GLError: 1281
04/08/2010 09:30:04 [WARNING] SLWP(465) Texture Load GLError: 1284
04/08/2010 09:30:07 [WARNING] SLWP(465) Background Load GLError: 1281
04/08/2010 09:30:09 [WARNING] SLWP(465) Texture Load GLError: 1284
04/08/2010 09:30:22 [WARNING] SLWP(465) Background Load GLError: 1281
04/08/2010 09:30:24 [WARNING] SLWP(465) Texture Load GLError: 1284
04/08/2010 09:30:27 [DEBUG] EglHelperSLWP(465) start()
04/08/2010 09:30:27 [DEBUG] EglHelperSLWP(465) reusing EGL
04/08/2010 09:30:27 [DEBUG] EglHelperSLWP(465) reusing display
04/08/2010 09:30:27 [DEBUG] EglHelperSLWP(465) reusing config
04/08/2010 09:30:27 [DEBUG] EglHelperSLWP(465) reusing context
04/08/2010 09:30:42 [WARNING] SLWP(465) Background Load GLError: 1281
04/08/2010 09:30:46 [DEBUG] EglHelperSLWP(465) start()
04/08/2010 09:30:46 [DEBUG] EglHelperSLWP(465) reusing EGL
04/08/2010 09:30:46 [DEBUG] EglHelperSLWP(465) reusing display
04/08/2010 09:30:46 [DEBUG] EglHelperSLWP(465) reusing config
04/08/2010 09:30:46 [DEBUG] EglHelperSLWP(465) reusing context
04/08/2010 09:38:34 [WARNING] SLWP(465) Background Load GLError: 1281
04/08/2010 09:38:39 [DEBUG] EglHelperSLWP(465) start()
04/08/2010 09:38:39 [DEBUG] EglHelperSLWP(465) reusing EGL
04/08/2010 09:38:39 [DEBUG] EglHelperSLWP(465) reusing display
04/08/2010 09:38:39 [DEBUG] EglHelperSLWP(465) reusing config
04/08/2010 09:38:39 [DEBUG] EglHelperSLWP(465) reusing context
04/08/2010 09:39:19 [WARNING] SLWP(465) Background Load GLError: 1281
04/08/2010 09:39:26 [DEBUG] EglHelperSLWP(465) start()
04/08/2010 09:39:26 [DEBUG] EglHelperSLWP(465) reusing EGL
04/08/2010 09:39:26 [DEBUG] EglHelperSLWP(465) reusing display
04/08/2010 09:39:26 [DEBUG] EglHelperSLWP(465) reusing config
04/08/2010 09:39:26 [DEBUG] EglHelperSLWP(465) reusing context
04/08/2010 09:41:46 [WARNING] SLWP(465) Background Load GLError: 1281
04/08/2010 09:41:50 [DEBUG] EglHelperSLWP(465) start()
04/08/2010 09:41:50 [DEBUG] EglHelperSLWP(465) reusing EGL
04/08/2010 09:41:50 [DEBUG] EglHelperSLWP(465) reusing display
04/08/2010 09:41:50 [DEBUG] EglHelperSLWP(465) reusing config
04/08/2010 09:41:50 [DEBUG] EglHelperSLWP(465) reusing context
04/08/2010 09:43:00 [WARNING] SLWP(465) Background Load GLError: 1281
04/08/2010 09:43:21 [DEBUG] EglHelperSLWP(465) start()
04/08/2010 09:43:21 [DEBUG] EglHelperSLWP(465) reusing EGL
04/08/2010 09:43:21 [DEBUG] EglHelperSLWP(465) reusing display
04/08/2010 09:43:21 [DEBUG] EglHelperSLWP(465) reusing config
04/08/2010 09:43:21 [DEBUG] EglHelperSLWP(465) reusing context
04/08/2010 09:43:58 [WARNING] SLWP(465) Background Load GLError: 1281
04/08/2010 09:44:01 [DEBUG] EglHelperSLWP(465) start()
04/08/2010 09:44:01 [DEBUG] EglHelperSLWP(465) reusing EGL
04/08/2010 09:44:01 [DEBUG] EglHelperSLWP(465) reusing display
04/08/2010 09:44:01 [DEBUG] EglHelperSLWP(465) reusing config
04/08/2010 09:44:01 [DEBUG] EglHelperSLWP(465) reusing context
04/08/2010 09:44:02 [WARNING] SLWP(465) Background Load GLError: 1281
04/08/2010 09:44:07 [WARNING] SLWP(465) Background Load GLError: 1281
04/08/2010 09:44:08 [DEBUG] EglHelperSLWP(465) start()
04/08/2010 09:44:08 [DEBUG] EglHelperSLWP(465) reusing EGL
04/08/2010 09:44:08 [DEBUG] EglHelperSLWP(465) reusing display
04/08/2010 09:44:08 [DEBUG] EglHelperSLWP(465) reusing config
04/08/2010 09:44:08 [DEBUG] EglHelperSLWP(465) reusing context
04/08/2010 09:44:09 [WARNING] SLWP(465) Texture Load GLError: 1384584
04/08/2010 09:44:09 [ERROR] AndroidRuntime(465)
java.lang.IllegalArgumentException
at com.google.android.gles_jni.EGLImpl.eglSwapBuffers(Native Method)
at com.seb.SLWP.EglHelper.swap(GLWallpaperService.java:446)
at com.seb.SLWP.GLThread.guardedRun(GLWallpaperService.java:687)
at com.seb.SLWP.GLThread.run(GLWallpaperService.java:539)

04/08/2010 09:44:11 [INFORMATION] ActivityManager(106) Process com.seb.SLWP
(pid 

Re: RE : Re: RE : [android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently

2010-04-08 Thread Robert Green
What's up with those 1281s?

On Apr 8, 2:53 am, seb boyart unix...@gmail.com wrote:
 Here's a crashlog.
 It happened on n1 after a rotation.
 Looks like the swap function is called with a wrong arg.
 04/08/2010 09:30:00 [DEBUG] EglHelperSLWP(465) start()
 04/08/2010 09:30:00 [DEBUG] EglHelperSLWP(465) getting new EGL
 04/08/2010 09:30:00 [DEBUG] EglHelperSLWP(465) getting new display
 04/08/2010 09:30:00 [DEBUG] EglHelperSLWP(465) getting new config
 04/08/2010 09:30:00 [DEBUG] EglHelperSLWP(465) creating new context
 04/08/2010 09:30:01 [WARNING] SLWP(465) Background Load GLError: 1281
 04/08/2010 09:30:02 [DEBUG] EglHelperSLWP(465) start()
 04/08/2010 09:30:02 [DEBUG] EglHelperSLWP(465) getting new EGL
 04/08/2010 09:30:02 [DEBUG] EglHelperSLWP(465) getting new display
 04/08/2010 09:30:02 [DEBUG] EglHelperSLWP(465) getting new config
 04/08/2010 09:30:02 [DEBUG] EglHelperSLWP(465) creating new context
 04/08/2010 09:30:03 [DEBUG] EglHelperSLWP(465) start()
 04/08/2010 09:30:03 [DEBUG] EglHelperSLWP(465) reusing EGL
 04/08/2010 09:30:03 [DEBUG] EglHelperSLWP(465) reusing display
 04/08/2010 09:30:03 [DEBUG] EglHelperSLWP(465) reusing config
 04/08/2010 09:30:03 [DEBUG] EglHelperSLWP(465) reusing context
 04/08/2010 09:30:03 [WARNING] SLWP(465) Background Load GLError: 1281
 04/08/2010 09:30:04 [WARNING] SLWP(465) Texture Load GLError: 1284
 04/08/2010 09:30:07 [WARNING] SLWP(465) Background Load GLError: 1281
 04/08/2010 09:30:09 [WARNING] SLWP(465) Texture Load GLError: 1284
 04/08/2010 09:30:22 [WARNING] SLWP(465) Background Load GLError: 1281
 04/08/2010 09:30:24 [WARNING] SLWP(465) Texture Load GLError: 1284
 04/08/2010 09:30:27 [DEBUG] EglHelperSLWP(465) start()
 04/08/2010 09:30:27 [DEBUG] EglHelperSLWP(465) reusing EGL
 04/08/2010 09:30:27 [DEBUG] EglHelperSLWP(465) reusing display
 04/08/2010 09:30:27 [DEBUG] EglHelperSLWP(465) reusing config
 04/08/2010 09:30:27 [DEBUG] EglHelperSLWP(465) reusing context
 04/08/2010 09:30:42 [WARNING] SLWP(465) Background Load GLError: 1281
 04/08/2010 09:30:46 [DEBUG] EglHelperSLWP(465) start()
 04/08/2010 09:30:46 [DEBUG] EglHelperSLWP(465) reusing EGL
 04/08/2010 09:30:46 [DEBUG] EglHelperSLWP(465) reusing display
 04/08/2010 09:30:46 [DEBUG] EglHelperSLWP(465) reusing config
 04/08/2010 09:30:46 [DEBUG] EglHelperSLWP(465) reusing context
 04/08/2010 09:38:34 [WARNING] SLWP(465) Background Load GLError: 1281
 04/08/2010 09:38:39 [DEBUG] EglHelperSLWP(465) start()
 04/08/2010 09:38:39 [DEBUG] EglHelperSLWP(465) reusing EGL
 04/08/2010 09:38:39 [DEBUG] EglHelperSLWP(465) reusing display
 04/08/2010 09:38:39 [DEBUG] EglHelperSLWP(465) reusing config
 04/08/2010 09:38:39 [DEBUG] EglHelperSLWP(465) reusing context
 04/08/2010 09:39:19 [WARNING] SLWP(465) Background Load GLError: 1281
 04/08/2010 09:39:26 [DEBUG] EglHelperSLWP(465) start()
 04/08/2010 09:39:26 [DEBUG] EglHelperSLWP(465) reusing EGL
 04/08/2010 09:39:26 [DEBUG] EglHelperSLWP(465) reusing display
 04/08/2010 09:39:26 [DEBUG] EglHelperSLWP(465) reusing config
 04/08/2010 09:39:26 [DEBUG] EglHelperSLWP(465) reusing context
 04/08/2010 09:41:46 [WARNING] SLWP(465) Background Load GLError: 1281
 04/08/2010 09:41:50 [DEBUG] EglHelperSLWP(465) start()
 04/08/2010 09:41:50 [DEBUG] EglHelperSLWP(465) reusing EGL
 04/08/2010 09:41:50 [DEBUG] EglHelperSLWP(465) reusing display
 04/08/2010 09:41:50 [DEBUG] EglHelperSLWP(465) reusing config
 04/08/2010 09:41:50 [DEBUG] EglHelperSLWP(465) reusing context
 04/08/2010 09:43:00 [WARNING] SLWP(465) Background Load GLError: 1281
 04/08/2010 09:43:21 [DEBUG] EglHelperSLWP(465) start()
 04/08/2010 09:43:21 [DEBUG] EglHelperSLWP(465) reusing EGL
 04/08/2010 09:43:21 [DEBUG] EglHelperSLWP(465) reusing display
 04/08/2010 09:43:21 [DEBUG] EglHelperSLWP(465) reusing config
 04/08/2010 09:43:21 [DEBUG] EglHelperSLWP(465) reusing context
 04/08/2010 09:43:58 [WARNING] SLWP(465) Background Load GLError: 1281
 04/08/2010 09:44:01 [DEBUG] EglHelperSLWP(465) start()
 04/08/2010 09:44:01 [DEBUG] EglHelperSLWP(465) reusing EGL
 04/08/2010 09:44:01 [DEBUG] EglHelperSLWP(465) reusing display
 04/08/2010 09:44:01 [DEBUG] EglHelperSLWP(465) reusing config
 04/08/2010 09:44:01 [DEBUG] EglHelperSLWP(465) reusing context
 04/08/2010 09:44:02 [WARNING] SLWP(465) Background Load GLError: 1281
 04/08/2010 09:44:07 [WARNING] SLWP(465) Background Load GLError: 1281
 04/08/2010 09:44:08 [DEBUG] EglHelperSLWP(465) start()
 04/08/2010 09:44:08 [DEBUG] EglHelperSLWP(465) reusing EGL
 04/08/2010 09:44:08 [DEBUG] EglHelperSLWP(465) reusing display
 04/08/2010 09:44:08 [DEBUG] EglHelperSLWP(465) reusing config
 04/08/2010 09:44:08 [DEBUG] EglHelperSLWP(465) reusing context
 04/08/2010 09:44:09 [WARNING] SLWP(465) Texture Load GLError: 1384584
 04/08/2010 09:44:09 [ERROR] AndroidRuntime(465)
 java.lang.IllegalArgumentException
 at com.google.android.gles_jni.EGLImpl.eglSwapBuffers(Native Method)
 at com.seb.SLWP.EglHelper.swap(GLWallpaperService.java:446)
 at 

[android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently

2010-04-07 Thread unixseb
i can't tell you if my code works for the droid (i dont own one) but
it help fixing issues on the N1.
anyway i still have issues, sometimes it looks like i have 2 opengl
surfaces swapping from each other after a resume.
i'm gonna implement your modifications and tell you the effect on the
N1
Thanks a lot for everything, my work would have never exists without
yours ! (and sorry for my poor english ;) )

On 6 avr, 22:58, Robert Green rbgrn@gmail.com wrote:
 That occasional lock-up started happening constantly to me.  I messed
 around with a few things and found that the Droid really doesn't like
 to have its Display and Context destroyed all the time.

 I modified the code so that it would reuse the display and context as
 much as possible.  I looked through my GLES book and it doesn't say
 explicitly that you should always destroy them when your surface
 changes so I have to assume that it must be ok.  Even if it's not -
 this works and it wasn't working before, so I'm using it.

 Here are the code modifications:

 In EglHelper:

     public void start() {
         Log.d(EglHelper + instanceId, start());
         if (mEgl == null) {
             Log.d(EglHelper + instanceId, getting new EGL);
             /*
              * Get an EGL instance
              */
             mEgl = (EGL10) EGLContext.getEGL();
         } else {
             Log.d(EglHelper + instanceId, reusing EGL);
         }

         if (mEglDisplay == null) {
             Log.d(EglHelper + instanceId, getting new display);
             /*
              * Get to the default display.
              */
             mEglDisplay =
 mEgl.eglGetDisplay(EGL10.EGL_DEFAULT_DISPLAY);
         } else {
             Log.d(EglHelper + instanceId, reusing display);
         }

         if (mEglConfig == null) {
             Log.d(EglHelper + instanceId, getting new config);
             /*
              * We can now initialize EGL for that display
              */
             int[] version = new int[2];
             mEgl.eglInitialize(mEglDisplay, version);
             mEglConfig = mEGLConfigChooser.chooseConfig(mEgl,
 mEglDisplay);
         } else {
             Log.d(EglHelper + instanceId, reusing config);
         }

         if (mEglContext == null) {
             Log.d(EglHelper + instanceId, creating new context);
             /*
              * Create an OpenGL ES context. This must be done only
 once, an OpenGL context is a somewhat heavy object.
              */
             mEglContext = mEGLContextFactory.createContext(mEgl,
 mEglDisplay, mEglConfig);
             if (mEglContext == null || mEglContext ==
 EGL10.EGL_NO_CONTEXT) {
                 throw new RuntimeException(createContext failed);
             }
         } else {
             Log.d(EglHelper + instanceId, reusing context);
         }

         mEglSurface = null;
     }

 In GLThread:

         private void stopEglLocked() {
             if (mHaveEgl) {
                 mHaveEgl = false;
                 mEglHelper.destroySurface();
                 sGLThreadManager.releaseEglSurface(this);
             }
         }

 Basically, you don't want a finish() in there.

 But we do need to finish somewhere so,

 At the end of guardedRun():

             } finally {
                 /*
                  * clean-up everything...
                  */
                 synchronized (sGLThreadManager) {
                     // Log.d(GLThread + getId(), Finishing.);
                     stopEglLocked();
                     mEglHelper.finish();
                 }
             }
         }

 Then Finally in GLWallpaperService:

         @Override
         public void onDestroy() {
             super.onDestroy();
             mGLThread.requestExitAndWait();
         }

 Of course you can remove any logging you don't want.

 The idea here is that we get to reuse the display and context on
 orientation changes which seems to make the Droid happy.  I haven't
 had a single crash since I switched to that, and I've probably
 reoriented 100 times since then in testing.

 I'll update the post on my blog to contain all the current code.

 On Apr 6, 2:57 pm, Robert Green rbgrn@gmail.com wrote:



  By the way - things seemed good but I'm still having the occasional
  lock-up.  The last one caused the phone to lock up badly enough that I
  had to pull the battery :(

  On Apr 6, 2:18 pm, Robert Green rbgrn@gmail.com wrote:

   I'm in disbelief, but it works!  Why does that hack work?  Is it a
   previous call to eglCreateWindowSurface which returns a bad value and
   after that, cleaning up causes a bad state and the next call to create
   window surface freezes?  I don't quite understand but I guess I never
   checked the return value of that call (because it wasn't returning
   when I was having problems, but maybe it was too late then :)).

   I tested and tested and tested again and this held up against all the
   orientation changes I could possibly make.  Good work!  I'll update
  

[android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently

2010-04-07 Thread unixseb
i'm currently using the code on your blog, i have an issue on N1, when
the orientation change, the surfacechanged function of the rendrerer
isn't called, so i can't reset the frustum to the correct window size.
i guess it's around the following code, i'm trying to fix it :

if (needStart) {
  tellRendererSurfaceCreated = true;
changed = true;
}
if (changed) {
gl = (GL10) 
mEglHelper.createSurface(mHolder);
tellRendererSurfaceChanged = true;
}
if (tellRendererSurfaceCreated) {
mRenderer.onSurfaceCreated(gl, 
mEglHelper.mEglConfig);
tellRendererSurfaceCreated = false;
}
if (tellRendererSurfaceChanged) {
mRenderer.onSurfaceChanged(gl, w, h);
tellRendererSurfaceChanged = false;
}


On 7 avr, 22:32, unixseb unix...@gmail.com wrote:
 i can't tell you if my code works for the droid (i dont own one) but
 it help fixing issues on the N1.
 anyway i still have issues, sometimes it looks like i have 2 opengl
 surfaces swapping from each other after a resume.
 i'm gonna implement your modifications and tell you the effect on the
 N1
 Thanks a lot for everything, my work would have never exists without
 yours ! (and sorry for my poor english ;) )

 On 6 avr, 22:58, Robert Green rbgrn@gmail.com wrote:



  That occasional lock-up started happening constantly to me.  I messed
  around with a few things and found that the Droid really doesn't like
  to have its Display and Context destroyed all the time.

  I modified the code so that it would reuse the display and context as
  much as possible.  I looked through my GLES book and it doesn't say
  explicitly that you should always destroy them when your surface
  changes so I have to assume that it must be ok.  Even if it's not -
  this works and it wasn't working before, so I'm using it.

  Here are the code modifications:

  In EglHelper:

      public void start() {
          Log.d(EglHelper + instanceId, start());
          if (mEgl == null) {
              Log.d(EglHelper + instanceId, getting new EGL);
              /*
               * Get an EGL instance
               */
              mEgl = (EGL10) EGLContext.getEGL();
          } else {
              Log.d(EglHelper + instanceId, reusing EGL);
          }

          if (mEglDisplay == null) {
              Log.d(EglHelper + instanceId, getting new display);
              /*
               * Get to the default display.
               */
              mEglDisplay =
  mEgl.eglGetDisplay(EGL10.EGL_DEFAULT_DISPLAY);
          } else {
              Log.d(EglHelper + instanceId, reusing display);
          }

          if (mEglConfig == null) {
              Log.d(EglHelper + instanceId, getting new config);
              /*
               * We can now initialize EGL for that display
               */
              int[] version = new int[2];
              mEgl.eglInitialize(mEglDisplay, version);
              mEglConfig = mEGLConfigChooser.chooseConfig(mEgl,
  mEglDisplay);
          } else {
              Log.d(EglHelper + instanceId, reusing config);
          }

          if (mEglContext == null) {
              Log.d(EglHelper + instanceId, creating new context);
              /*
               * Create an OpenGL ES context. This must be done only
  once, an OpenGL context is a somewhat heavy object.
               */
              mEglContext = mEGLContextFactory.createContext(mEgl,
  mEglDisplay, mEglConfig);
              if (mEglContext == null || mEglContext ==
  EGL10.EGL_NO_CONTEXT) {
                  throw new RuntimeException(createContext failed);
              }
          } else {
              Log.d(EglHelper + instanceId, reusing context);
          }

          mEglSurface = null;
      }

  In GLThread:

          private void stopEglLocked() {
              if (mHaveEgl) {
                  mHaveEgl = false;
                  mEglHelper.destroySurface();
                  sGLThreadManager.releaseEglSurface(this);
              }
          }

  Basically, you don't want a finish() in there.

  But we do need to finish somewhere so,

  At the end of guardedRun():

              } finally {
                  /*
                   * clean-up everything...
                   */
                  synchronized (sGLThreadManager) {
                      // Log.d(GLThread + getId(), Finishing.);
                      stopEglLocked();
                      mEglHelper.finish();
                  }
              }
          }

  Then Finally in 

[android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently

2010-04-07 Thread Robert Green
That's strange..

First of all, how are you getting orientation changes on an N1?  I
never found a way to get it to do that.

I tested my latest code on www.rbgrn.net on both the N1 and Droid and
both seem to be working well now.  It includes your wait-hack and my
updates.

On Apr 7, 3:57 pm, unixseb unix...@gmail.com wrote:
 i'm currently using the code on your blog, i have an issue on N1, when
 the orientation change, the surfacechanged function of the rendrerer
 isn't called, so i can't reset the frustum to the correct window size.
 i guess it's around the following code, i'm trying to fix it :

                         if (needStart) {
                               tellRendererSurfaceCreated = true;
                                         changed = true;
                                 }
                                 if (changed) {
                                         gl = (GL10) 
 mEglHelper.createSurface(mHolder);
                                         tellRendererSurfaceChanged = true;
                                 }
                                 if (tellRendererSurfaceCreated) {
                                         mRenderer.onSurfaceCreated(gl, 
 mEglHelper.mEglConfig);
                                         tellRendererSurfaceCreated = false;
                                 }
                                 if (tellRendererSurfaceChanged) {
                                         mRenderer.onSurfaceChanged(gl, w, h);
                                         tellRendererSurfaceChanged = false;
                                 }

 On 7 avr, 22:32, unixseb unix...@gmail.com wrote:



  i can't tell you if my code works for the droid (i dont own one) but
  it help fixing issues on the N1.
  anyway i still have issues, sometimes it looks like i have 2 opengl
  surfaces swapping from each other after a resume.
  i'm gonna implement your modifications and tell you the effect on the
  N1
  Thanks a lot for everything, my work would have never exists without
  yours ! (and sorry for my poor english ;) )

  On 6 avr, 22:58, Robert Green rbgrn@gmail.com wrote:

   That occasional lock-up started happening constantly to me.  I messed
   around with a few things and found that the Droid really doesn't like
   to have its Display and Context destroyed all the time.

   I modified the code so that it would reuse the display and context as
   much as possible.  I looked through my GLES book and it doesn't say
   explicitly that you should always destroy them when your surface
   changes so I have to assume that it must be ok.  Even if it's not -
   this works and it wasn't working before, so I'm using it.

   Here are the code modifications:

   In EglHelper:

       public void start() {
           Log.d(EglHelper + instanceId, start());
           if (mEgl == null) {
               Log.d(EglHelper + instanceId, getting new EGL);
               /*
                * Get an EGL instance
                */
               mEgl = (EGL10) EGLContext.getEGL();
           } else {
               Log.d(EglHelper + instanceId, reusing EGL);
           }

           if (mEglDisplay == null) {
               Log.d(EglHelper + instanceId, getting new display);
               /*
                * Get to the default display.
                */
               mEglDisplay =
   mEgl.eglGetDisplay(EGL10.EGL_DEFAULT_DISPLAY);
           } else {
               Log.d(EglHelper + instanceId, reusing display);
           }

           if (mEglConfig == null) {
               Log.d(EglHelper + instanceId, getting new config);
               /*
                * We can now initialize EGL for that display
                */
               int[] version = new int[2];
               mEgl.eglInitialize(mEglDisplay, version);
               mEglConfig = mEGLConfigChooser.chooseConfig(mEgl,
   mEglDisplay);
           } else {
               Log.d(EglHelper + instanceId, reusing config);
           }

           if (mEglContext == null) {
               Log.d(EglHelper + instanceId, creating new context);
               /*
                * Create an OpenGL ES context. This must be done only
   once, an OpenGL context is a somewhat heavy object.
                */
               mEglContext = mEGLContextFactory.createContext(mEgl,
   mEglDisplay, mEglConfig);
               if (mEglContext == null || mEglContext ==
   EGL10.EGL_NO_CONTEXT) {
                   throw new RuntimeException(createContext failed);
               }
           } else {
               Log.d(EglHelper + instanceId, reusing context);
           }

           mEglSurface = null;
       }

   In GLThread:

           private void stopEglLocked() {
               if (mHaveEgl) {
                   mHaveEgl = false;
                   mEglHelper.destroySurface();
                   sGLThreadManager.releaseEglSurface(this);
               }
           }

   Basically, you don't want a finish() in there.

   But we do need to finish somewhere 

RE : [android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently

2010-04-07 Thread seb boyart
I use helixlauncher2 to rotate the desktop on n1.

Le 7 avr. 2010 23:01, Robert Green rbgrn@gmail.com a écrit :

That's strange..

First of all, how are you getting orientation changes on an N1?  I
never found a way to get it to do that.

I tested my latest code on www.rbgrn.net on both the N1 and Droid and
both seem to be working well now.  It includes your wait-hack and my
updates.

On Apr 7, 3:57 pm, unixseb unix...@gmail.com wrote:
 i'm currently using the code on your blog, i have an issue on N1, when
 the orientation change, the surfacechanged function of the rendrerer
 isn't called, so i can't reset the frustum to the correct window size.
 i guess it's around the following code, i'm trying to fix it :

 if (needStart) {
   tellRendererSurfaceCreated = true;
 changed = true;
 }
 if (changed) {
 gl = (GL10)
mEglHelper.createSurface(mHolder);
 tellRendererSurfaceChanged = true;
 }
 if (tellRendererSurfaceCreated) {
 mRenderer.onSurfaceCreated(gl,
mEglHelper.mEglConfig);
 tellRendererSurfaceCreated =
false;
 }
 if (tellRendererSurfaceChanged) {
 mRenderer.onSurfaceChanged(gl, w,
h);
 tellRendererSurfaceChanged =
false;
 }

 On 7 avr, 22:32, unixseb unix...@gmail.com wrote:



  i can't tell you if my code works for the droid (i dont own one) but
  it help fixing issues on the N1.
  anyway i still have issues, sometimes it looks like i have 2 opengl
  surfaces swapping from each other after a resume.
  i'm gonna implement your modifications and tell you the effect on the
  N1
  Thanks a lot for everything, my work would have never exists without
  yours ! (and sorry for my poor english ;) )

  On 6 avr, 22:58, Robert Green rbgrn@gmail.com wrote:

   That occasional lock-up started happening constantly to me.  I messed
   around with a few things and found that the Droid really doesn't like
   to have its Display and Context destroyed all the time.

   I modified the code so that it would reuse the display and context as
   much as possible.  I looked through my GLES book and it doesn't say
   explicitly that you should always destroy them when your surface
   changes so I have to assume that it must be ok.  Even if it's not -
   this works and it wasn't working before, so I'm using it.

   Here are the code modifications:

   In EglHelper:

   public void start() {
   Log.d(EglHelper + instanceId, start());
   if (mEgl == null) {
   Log.d(EglHelper + instanceId, getting new EGL);
   /*
* Get an EGL instance
*/
   mEgl = (EGL10) EGLContext.getEGL();
   } else {
   Log.d(EglHelper + instanceId, reusing EGL);
   }

   if (mEglDisplay == null) {
   Log.d(EglHelper + instanceId, getting new display);
   /*
* Get to the default display.
*/
   mEglDisplay =
   mEgl.eglGetDisplay(EGL10.EGL_DEFAULT_DISPLAY);
   } else {
   Log.d(EglHelper + instanceId, reusing display);
   }

   if (mEglConfig == null) {
   Log.d(EglHelper + instanceId, getting new config);
   /*
* We can now initialize EGL for that display
*/
   int[] version = new int[2];
   mEgl.eglInitialize(mEglDisplay, version);
   mEglConfig = mEGLConfigChooser.chooseConfig(mEgl,
   mEglDisplay);
   } else {
   Log.d(EglHelper + instanceId, reusing config);
   }

   if (mEglContext == null) {
   Log.d(EglHelper + instanceId, creating new context);
   /*
* Create an OpenGL ES context. This must be done only
   once, an OpenGL context is a somewhat heavy object.
*/
   mEglContext = mEGLContextFactory.createContext(mEgl,
   mEglDisplay, mEglConfig);
   if (mEglContext == null || mEglContext ==
   EGL10.EGL_NO_CONTEXT) {
   throw new RuntimeException(createContext failed);
   }
   } else {
   Log.d(EglHelper + instanceId, reusing context);
   }

   mEglSurface = null;
   }

   In GLThread:

   private void stopEglLocked() {
   if (mHaveEgl) {
   mHaveEgl = false;
   mEglHelper.destroySurface();
   sGLThreadManager.releaseEglSurface(this);
   

Re: RE : [android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently

2010-04-07 Thread Ralf Schneider
I didn't know about helixlauncher2. It's cool!

Now I can navigate the home screen just with the thumb. That never worked
reliable for me with the stock homescreen of the N1.

And everything is smooth. Feels like an iphone...

2010/4/7 seb boyart unix...@gmail.com

 I use helixlauncher2 to rotate the desktop on n1.

 Le 7 avr. 2010 23:01, Robert Green rbgrn@gmail.com a écrit :


 That's strange..

 First of all, how are you getting orientation changes on an N1?  I
 never found a way to get it to do that.

 I tested my latest code on www.rbgrn.net on both the N1 and Droid and
 both seem to be working well now.  It includes your wait-hack and my
 updates.

 On Apr 7, 3:57 pm, unixseb unix...@gmail.com wrote:
  i'm currently using the code on your blog, i have an issue on N1, when
  the orientation change, the surfacechanged function of the rendrerer
  isn't called, so i can't reset the frustum to the correct window size.
  i guess it's around the following code, i'm trying to fix it :
 
  if (needStart) {
tellRendererSurfaceCreated = true;
  changed = true;
  }
  if (changed) {
  gl = (GL10)
 mEglHelper.createSurface(mHolder);
  tellRendererSurfaceChanged =
 true;
  }
  if (tellRendererSurfaceCreated) {
  mRenderer.onSurfaceCreated(gl,
 mEglHelper.mEglConfig);
  tellRendererSurfaceCreated =
 false;
  }
  if (tellRendererSurfaceChanged) {
  mRenderer.onSurfaceChanged(gl, w,
 h);
  tellRendererSurfaceChanged =
 false;
  }
 
  On 7 avr, 22:32, unixseb unix...@gmail.com wrote:
 
 
 
   i can't tell you if my code works for the droid (i dont own one) but
   it help fixing issues on the N1.
   anyway i still have issues, sometimes it looks like i have 2 opengl
   surfaces swapping from each other after a resume.
   i'm gonna implement your modifications and tell you the effect on the
   N1
   Thanks a lot for everything, my work would have never exists without
   yours ! (and sorry for my poor english ;) )
 
   On 6 avr, 22:58, Robert Green rbgrn@gmail.com wrote:
 
That occasional lock-up started happening constantly to me.  I messed
around with a few things and found that the Droid really doesn't like
to have its Display and Context destroyed all the time.
 
I modified the code so that it would reuse the display and context as
much as possible.  I looked through my GLES book and it doesn't say
explicitly that you should always destroy them when your surface
changes so I have to assume that it must be ok.  Even if it's not -
this works and it wasn't working before, so I'm using it.
 
Here are the code modifications:
 
In EglHelper:
 
public void start() {
Log.d(EglHelper + instanceId, start());
if (mEgl == null) {
Log.d(EglHelper + instanceId, getting new EGL);
/*
 * Get an EGL instance
 */
mEgl = (EGL10) EGLContext.getEGL();
} else {
Log.d(EglHelper + instanceId, reusing EGL);
}
 
if (mEglDisplay == null) {
Log.d(EglHelper + instanceId, getting new display);
/*
 * Get to the default display.
 */
mEglDisplay =
mEgl.eglGetDisplay(EGL10.EGL_DEFAULT_DISPLAY);
} else {
Log.d(EglHelper + instanceId, reusing display);
}
 
if (mEglConfig == null) {
Log.d(EglHelper + instanceId, getting new config);
/*
 * We can now initialize EGL for that display
 */
int[] version = new int[2];
mEgl.eglInitialize(mEglDisplay, version);
mEglConfig = mEGLConfigChooser.chooseConfig(mEgl,
mEglDisplay);
} else {
Log.d(EglHelper + instanceId, reusing config);
}
 
if (mEglContext == null) {
Log.d(EglHelper + instanceId, creating new context);
/*
 * Create an OpenGL ES context. This must be done only
once, an OpenGL context is a somewhat heavy object.
 */
mEglContext = mEGLContextFactory.createContext(mEgl,
mEglDisplay, mEglConfig);
if (mEglContext == null || mEglContext ==
EGL10.EGL_NO_CONTEXT) {
throw new RuntimeException(createContext failed);
}

Re: RE : [android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently

2010-04-07 Thread seb boyart
forget it, your code is fine, it call the surfacechanged right, passing good
values for width and height.
for obvious reasons, my sphere isn't restreched after a rotation (it does
approx 5% of the time only), but all initialization is done
in surfacechanged using passed width and height, it worked fine before, but
not anymore.
anyway the code on the blog look fine, i just had to declare the instanceId
var and cast a return value to Runnable to compile it.
i'm gonna publish a commentary with a link to your blog in the code, do you
want something special in it ?

2010/4/7 seb boyart unix...@gmail.com

 I use helixlauncher2 to rotate the desktop on n1.

 Le 7 avr. 2010 23:01, Robert Green rbgrn@gmail.com a écrit :


 That's strange..

 First of all, how are you getting orientation changes on an N1?  I
 never found a way to get it to do that.

 I tested my latest code on www.rbgrn.net on both the N1 and Droid and
 both seem to be working well now.  It includes your wait-hack and my
 updates.

 On Apr 7, 3:57 pm, unixseb unix...@gmail.com wrote:
  i'm currently using the code on your blog, i have an issue on N1, when
  the orientation change, the surfacechanged function of the rendrerer
  isn't called, so i can't reset the frustum to the correct window size.
  i guess it's around the following code, i'm trying to fix it :
 
  if (needStart) {
tellRendererSurfaceCreated = true;
  changed = true;
  }
  if (changed) {
  gl = (GL10)
 mEglHelper.createSurface(mHolder);
  tellRendererSurfaceChanged =
 true;
  }
  if (tellRendererSurfaceCreated) {
  mRenderer.onSurfaceCreated(gl,
 mEglHelper.mEglConfig);
  tellRendererSurfaceCreated =
 false;
  }
  if (tellRendererSurfaceChanged) {
  mRenderer.onSurfaceChanged(gl, w,
 h);
  tellRendererSurfaceChanged =
 false;
  }
 
  On 7 avr, 22:32, unixseb unix...@gmail.com wrote:
 
 
 
   i can't tell you if my code works for the droid (i dont own one) but
   it help fixing issues on the N1.
   anyway i still have issues, sometimes it looks like i have 2 opengl
   surfaces swapping from each other after a resume.
   i'm gonna implement your modifications and tell you the effect on the
   N1
   Thanks a lot for everything, my work would have never exists without
   yours ! (and sorry for my poor english ;) )
 
   On 6 avr, 22:58, Robert Green rbgrn@gmail.com wrote:
 
That occasional lock-up started happening constantly to me.  I messed
around with a few things and found that the Droid really doesn't like
to have its Display and Context destroyed all the time.
 
I modified the code so that it would reuse the display and context as
much as possible.  I looked through my GLES book and it doesn't say
explicitly that you should always destroy them when your surface
changes so I have to assume that it must be ok.  Even if it's not -
this works and it wasn't working before, so I'm using it.
 
Here are the code modifications:
 
In EglHelper:
 
public void start() {
Log.d(EglHelper + instanceId, start());
if (mEgl == null) {
Log.d(EglHelper + instanceId, getting new EGL);
/*
 * Get an EGL instance
 */
mEgl = (EGL10) EGLContext.getEGL();
} else {
Log.d(EglHelper + instanceId, reusing EGL);
}
 
if (mEglDisplay == null) {
Log.d(EglHelper + instanceId, getting new display);
/*
 * Get to the default display.
 */
mEglDisplay =
mEgl.eglGetDisplay(EGL10.EGL_DEFAULT_DISPLAY);
} else {
Log.d(EglHelper + instanceId, reusing display);
}
 
if (mEglConfig == null) {
Log.d(EglHelper + instanceId, getting new config);
/*
 * We can now initialize EGL for that display
 */
int[] version = new int[2];
mEgl.eglInitialize(mEglDisplay, version);
mEglConfig = mEGLConfigChooser.chooseConfig(mEgl,
mEglDisplay);
} else {
Log.d(EglHelper + instanceId, reusing config);
}
 
if (mEglContext == null) {
Log.d(EglHelper + instanceId, creating new context);
/*
 * Create an OpenGL ES context. This must be done only

[android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently

2010-04-06 Thread unixseb
have a look at the svn repository on code.google.com/project/earth-
live-wallpaper
the hack int the glwallpaperservice class avoid some crashes with
screen rotation on droids.

On 5 avr, 20:24, Robert Green rbgrn@gmail.com wrote:
 Oh, so you solved it??  What's the issue and what's the workaround?

 On Apr 4, 3:33 pm, unixseb unix...@gmail.com wrote:



  i can help you,
  i'm having this issue with earth live wallpaper.
  i tracked a bug in the swap function taht causes service dies, but i
  was looking for this one for a long time now !

  On 3 avr, 23:56, Robert Green rbgrn@gmail.com wrote:

   I've had this reported to me by a few people using the
  GLWallpaperServicecode I posted.  I've been debugging this for hours
   and have so far tracked the problem down to
   egl.eglCreateWindowSurface(display, config, nativeWindow, null);

   It never returns and every notifyAll() after that results in:
   W/SharedBufferStack( 1030): waitForCondition(ReallocateCondition)
   timed out (identity=288, status=0). CPU may be pegged. trying again.

   It seems to happen when switching orientation - so when the surface is
   being destroyed/recreated and more specifically when calls to render
   the frame are being made at the same time.  If there are no render
   calls happening while switching, things seem mostly ok.  I'm debugging
   this further but I feel like a method like that should never
   deadlock.  Seems like a bug somewhere below the line to me.

   Since none of the GL init code from the shipped live wallpapers was
   posted anywhere, I have no good reference to use for how to properly
   handle the window resizing.  Clearly the code I'm using does it a
   little differently but I still feel like a deadlock like this should
   not occur.

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe, reply using remove me as the subject.


Re: [android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently

2010-04-06 Thread Ralf Schneider
I'm also interested in this topic. I got an 404 on the link: This seems to
work:

http://code.google.com/p/earth-live-wallpaper/

Thank you for sharing your code!

2010/4/6 unixseb unix...@gmail.com

 have a look at the svn repository on code.google.com/project/earth-
 live-wallpaper http://code.google.com/project/earth-%0Alive-wallpaper
 the hack int the glwallpaperservice class avoid some crashes with
 screen rotation on droids.

 On 5 avr, 20:24, Robert Green rbgrn@gmail.com wrote:
  Oh, so you solved it??  What's the issue and what's the workaround?
 
  On Apr 4, 3:33 pm, unixseb unix...@gmail.com wrote:
 
 
 
   i can help you,
   i'm having this issue with earth live wallpaper.
   i tracked a bug in the swap function taht causes service dies, but i
   was looking for this one for a long time now !
 
   On 3 avr, 23:56, Robert Green rbgrn@gmail.com wrote:
 
I've had this reported to me by a few people using the
   GLWallpaperServicecode I posted.  I've been debugging this for hours
and have so far tracked the problem down to
egl.eglCreateWindowSurface(display, config, nativeWindow, null);
 
It never returns and every notifyAll() after that results in:
W/SharedBufferStack( 1030): waitForCondition(ReallocateCondition)
timed out (identity=288, status=0). CPU may be pegged. trying again.
 
It seems to happen when switching orientation - so when the surface
 is
being destroyed/recreated and more specifically when calls to render
the frame are being made at the same time.  If there are no render
calls happening while switching, things seem mostly ok.  I'm
 debugging
this further but I feel like a method like that should never
deadlock.  Seems like a bug somewhere below the line to me.
 
Since none of the GL init code from the shipped live wallpapers was
posted anywhere, I have no good reference to use for how to properly
handle the window resizing.  Clearly the code I'm using does it a
little differently but I still feel like a deadlock like this should
not occur.

 --
 You received this message because you are subscribed to the Google
 Groups Android Developers group.
 To post to this group, send email to android-developers@googlegroups.com
 To unsubscribe from this group, send email to
 android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/android-developers?hl=en

 To unsubscribe, reply using remove me as the subject.


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently

2010-04-06 Thread shaun
Assuming I correctly identified the code that unixseb uses as the
workaround/fix for orientation changes on Droid in Live Wallpaper with
OpenGL, the following code is the same with the exception of
recursion:

public EGLSurface createWindowSurface(EGL10 egl, EGLDisplay
display, EGLConfig config, Object nativeWindow) {
EGLSurface eglSurface = null;
while (eglSurface == null) {
try {
eglSurface = egl.eglCreateWindowSurface(display,
config, nativeWindow, null);
} catch (Throwable t) {
} finally {
if (eglSurface == null) {
try {
Thread.sleep(10);
} catch (InterruptedException t) {
}
}
}

}
return eglSurface;
}



I'd like to know if unixseb's fix works for others.  I still cannot
test.


On Apr 6, 11:00 am, Ralf Schneider li...@gestaltgeber.com wrote:
 I'm also interested in this topic. I got an 404 on the link: This seems to
 work:

 http://code.google.com/p/earth-live-wallpaper/

 Thank you for sharing your code!

 2010/4/6 unixseb unix...@gmail.com



  have a look at the svn repository on code.google.com/project/earth-
  live-wallpaper http://code.google.com/project/earth-%0Alive-wallpaper
  the hack int the glwallpaperservice class avoid some crashes with
  screen rotation on droids.

  On 5 avr, 20:24, Robert Green rbgrn@gmail.com wrote:
   Oh, so you solved it??  What's the issue and what's the workaround?

   On Apr 4, 3:33 pm, unixseb unix...@gmail.com wrote:

i can help you,
i'm having this issue with earth live wallpaper.
i tracked a bug in the swap function taht causes service dies, but i
was looking for this one for a long time now !

On 3 avr, 23:56, Robert Green rbgrn@gmail.com wrote:

 I've had this reported to me by a few people using the
GLWallpaperServicecode I posted.  I've been debugging this for hours
 and have so far tracked the problem down to
 egl.eglCreateWindowSurface(display, config, nativeWindow, null);

 It never returns and every notifyAll() after that results in:
 W/SharedBufferStack( 1030): waitForCondition(ReallocateCondition)
 timed out (identity=288, status=0). CPU may be pegged. trying again.

 It seems to happen when switching orientation - so when the surface
  is
 being destroyed/recreated and more specifically when calls to render
 the frame are being made at the same time.  If there are no render
 calls happening while switching, things seem mostly ok.  I'm
  debugging
 this further but I feel like a method like that should never
 deadlock.  Seems like a bug somewhere below the line to me.

 Since none of the GL init code from the shipped live wallpapers was
 posted anywhere, I have no good reference to use for how to properly
 handle the window resizing.  Clearly the code I'm using does it a
 little differently but I still feel like a deadlock like this should
 not occur.

  --
  You received this message because you are subscribed to the Google
  Groups Android Developers group.
  To post to this group, send email to android-developers@googlegroups.com
  To unsubscribe from this group, send email to
  android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubs­cr...@googlegroups.com
  For more options, visit this group at
 http://groups.google.com/group/android-developers?hl=en

  To unsubscribe, reply using remove me as the subject.- Hide quoted text -

 - Show quoted text -

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en


[android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently

2010-04-06 Thread Robert Green
I'm in disbelief, but it works!  Why does that hack work?  Is it a
previous call to eglCreateWindowSurface which returns a bad value and
after that, cleaning up causes a bad state and the next call to create
window surface freezes?  I don't quite understand but I guess I never
checked the return value of that call (because it wasn't returning
when I was having problems, but maybe it was too late then :)).

I tested and tested and tested again and this held up against all the
orientation changes I could possibly make.  Good work!  I'll update
the code I posted.

BTW - I'm still seeing the occasional:
E/libEGL  ( 5769): eglChooseConfig:897 error 3005 (EGL_BAD_CONFIG)
W/dalvikvm( 5769): threadid=13: thread exiting with uncaught exception
(group=0x4001b180)
E/AndroidRuntime( 5769): Uncaught handler: thread GLThread 7 exiting
due to uncaught exception
E/AndroidRuntime( 5769): java.lang.IllegalArgumentException
E/AndroidRuntime( 5769):at
com.google.android.gles_jni.EGLImpl.eglGetConfigAttrib(Native Method)
E/AndroidRuntime( 5769):at android.opengl.EglHelper
$ComponentSizeChooser.findConfigAttrib(EglHelper.java:1007)
E/AndroidRuntime( 5769):at android.opengl.EglHelper
$ComponentSizeChooser.chooseConfig(EglHelper.java:987)
E/AndroidRuntime( 5769):at android.opengl.EglHelper
$BaseConfigChooser.chooseConfig(EglHelper.java:951)
E/AndroidRuntime( 5769):at
android.opengl.EglHelper.start(EglHelper.java:127)
E/AndroidRuntime( 5769):at android.opengl.EglHelper
$GLThread.guardedRun(EglHelper.java:421)
E/AndroidRuntime( 5769):at android.opengl.EglHelper
$GLThread.run(EglHelper.java:358)

I'm trying to track that one down but it's very hard to recreate.  It
likes to happen the first time you run a newly installed gl live
wallpaper but then it doesn't happen again for a while.

Thanks guys for all your help!

On Apr 6, 11:29 am, shaun shashepp...@gmail.com wrote:
 Assuming I correctly identified the code that unixseb uses as the
 workaround/fix for orientation changes on Droid in Live Wallpaper with
 OpenGL, the following code is the same with the exception of
 recursion:

     public EGLSurface createWindowSurface(EGL10 egl, EGLDisplay
 display, EGLConfig config, Object nativeWindow) {
         EGLSurface eglSurface = null;
         while (eglSurface == null) {
             try {
                 eglSurface = egl.eglCreateWindowSurface(display,
 config, nativeWindow, null);
             } catch (Throwable t) {
             } finally {
                 if (eglSurface == null) {
                     try {
                         Thread.sleep(10);
                     } catch (InterruptedException t) {
                     }
                 }
             }

         }
         return eglSurface;
     }

 I'd like to know if unixseb's fix works for others.  I still cannot
 test.

 On Apr 6, 11:00 am, Ralf Schneider li...@gestaltgeber.com wrote:



  I'm also interested in this topic. I got an 404 on the link: This seems to
  work:

 http://code.google.com/p/earth-live-wallpaper/

  Thank you for sharing your code!

  2010/4/6 unixseb unix...@gmail.com

   have a look at the svn repository on code.google.com/project/earth-
   live-wallpaper http://code.google.com/project/earth-%0Alive-wallpaper
   the hack int the glwallpaperservice class avoid some crashes with
   screen rotation on droids.

   On 5 avr, 20:24, Robert Green rbgrn@gmail.com wrote:
Oh, so you solved it??  What's the issue and what's the workaround?

On Apr 4, 3:33 pm, unixseb unix...@gmail.com wrote:

 i can help you,
 i'm having this issue with earth live wallpaper.
 i tracked a bug in the swap function taht causes service dies, but i
 was looking for this one for a long time now !

 On 3 avr, 23:56, Robert Green rbgrn@gmail.com wrote:

  I've had this reported to me by a few people using the
 GLWallpaperServicecode I posted.  I've been debugging this for hours
  and have so far tracked the problem down to
  egl.eglCreateWindowSurface(display, config, nativeWindow, null);

  It never returns and every notifyAll() after that results in:
  W/SharedBufferStack( 1030): waitForCondition(ReallocateCondition)
  timed out (identity=288, status=0). CPU may be pegged. trying again.

  It seems to happen when switching orientation - so when the surface
   is
  being destroyed/recreated and more specifically when calls to render
  the frame are being made at the same time.  If there are no render
  calls happening while switching, things seem mostly ok.  I'm
   debugging
  this further but I feel like a method like that should never
  deadlock.  Seems like a bug somewhere below the line to me.

  Since none of the GL init code from the shipped live wallpapers was
  posted anywhere, I have no good reference to use for how to properly
  handle the window resizing.  Clearly the code I'm using does it a
  little 

[android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently

2010-04-06 Thread Robert Green
By the way - things seemed good but I'm still having the occasional
lock-up.  The last one caused the phone to lock up badly enough that I
had to pull the battery :(

On Apr 6, 2:18 pm, Robert Green rbgrn@gmail.com wrote:
 I'm in disbelief, but it works!  Why does that hack work?  Is it a
 previous call to eglCreateWindowSurface which returns a bad value and
 after that, cleaning up causes a bad state and the next call to create
 window surface freezes?  I don't quite understand but I guess I never
 checked the return value of that call (because it wasn't returning
 when I was having problems, but maybe it was too late then :)).

 I tested and tested and tested again and this held up against all the
 orientation changes I could possibly make.  Good work!  I'll update
 the code I posted.

 BTW - I'm still seeing the occasional:
 E/libEGL  ( 5769): eglChooseConfig:897 error 3005 (EGL_BAD_CONFIG)
 W/dalvikvm( 5769): threadid=13: thread exiting with uncaught exception
 (group=0x4001b180)
 E/AndroidRuntime( 5769): Uncaught handler: thread GLThread 7 exiting
 due to uncaught exception
 E/AndroidRuntime( 5769): java.lang.IllegalArgumentException
 E/AndroidRuntime( 5769):        at
 com.google.android.gles_jni.EGLImpl.eglGetConfigAttrib(Native Method)
 E/AndroidRuntime( 5769):        at android.opengl.EglHelper
 $ComponentSizeChooser.findConfigAttrib(EglHelper.java:1007)
 E/AndroidRuntime( 5769):        at android.opengl.EglHelper
 $ComponentSizeChooser.chooseConfig(EglHelper.java:987)
 E/AndroidRuntime( 5769):        at android.opengl.EglHelper
 $BaseConfigChooser.chooseConfig(EglHelper.java:951)
 E/AndroidRuntime( 5769):        at
 android.opengl.EglHelper.start(EglHelper.java:127)
 E/AndroidRuntime( 5769):        at android.opengl.EglHelper
 $GLThread.guardedRun(EglHelper.java:421)
 E/AndroidRuntime( 5769):        at android.opengl.EglHelper
 $GLThread.run(EglHelper.java:358)

 I'm trying to track that one down but it's very hard to recreate.  It
 likes to happen the first time you run a newly installed gl live
 wallpaper but then it doesn't happen again for a while.

 Thanks guys for all your help!

 On Apr 6, 11:29 am, shaun shashepp...@gmail.com wrote:



  Assuming I correctly identified the code that unixseb uses as the
  workaround/fix for orientation changes on Droid in Live Wallpaper with
  OpenGL, the following code is the same with the exception of
  recursion:

      public EGLSurface createWindowSurface(EGL10 egl, EGLDisplay
  display, EGLConfig config, Object nativeWindow) {
          EGLSurface eglSurface = null;
          while (eglSurface == null) {
              try {
                  eglSurface = egl.eglCreateWindowSurface(display,
  config, nativeWindow, null);
              } catch (Throwable t) {
              } finally {
                  if (eglSurface == null) {
                      try {
                          Thread.sleep(10);
                      } catch (InterruptedException t) {
                      }
                  }
              }

          }
          return eglSurface;
      }

  I'd like to know if unixseb's fix works for others.  I still cannot
  test.

  On Apr 6, 11:00 am, Ralf Schneider li...@gestaltgeber.com wrote:

   I'm also interested in this topic. I got an 404 on the link: This seems to
   work:

  http://code.google.com/p/earth-live-wallpaper/

   Thank you for sharing your code!

   2010/4/6 unixseb unix...@gmail.com

have a look at the svn repository on code.google.com/project/earth-
live-wallpaper http://code.google.com/project/earth-%0Alive-wallpaper
the hack int the glwallpaperservice class avoid some crashes with
screen rotation on droids.

On 5 avr, 20:24, Robert Green rbgrn@gmail.com wrote:
 Oh, so you solved it??  What's the issue and what's the workaround?

 On Apr 4, 3:33 pm, unixseb unix...@gmail.com wrote:

  i can help you,
  i'm having this issue with earth live wallpaper.
  i tracked a bug in the swap function taht causes service dies, but i
  was looking for this one for a long time now !

  On 3 avr, 23:56, Robert Green rbgrn@gmail.com wrote:

   I've had this reported to me by a few people using the
  GLWallpaperServicecode I posted.  I've been debugging this for 
  hours
   and have so far tracked the problem down to
   egl.eglCreateWindowSurface(display, config, nativeWindow, null);

   It never returns and every notifyAll() after that results in:
   W/SharedBufferStack( 1030): waitForCondition(ReallocateCondition)
   timed out (identity=288, status=0). CPU may be pegged. trying 
   again.

   It seems to happen when switching orientation - so when the 
   surface
is
   being destroyed/recreated and more specifically when calls to 
   render
   the frame are being made at the same time.  If there are no render
   calls happening while switching, things seem mostly ok.  I'm
debugging
   this further but 

[android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently

2010-04-06 Thread Robert Green
That occasional lock-up started happening constantly to me.  I messed
around with a few things and found that the Droid really doesn't like
to have its Display and Context destroyed all the time.

I modified the code so that it would reuse the display and context as
much as possible.  I looked through my GLES book and it doesn't say
explicitly that you should always destroy them when your surface
changes so I have to assume that it must be ok.  Even if it's not -
this works and it wasn't working before, so I'm using it.

Here are the code modifications:

In EglHelper:

public void start() {
Log.d(EglHelper + instanceId, start());
if (mEgl == null) {
Log.d(EglHelper + instanceId, getting new EGL);
/*
 * Get an EGL instance
 */
mEgl = (EGL10) EGLContext.getEGL();
} else {
Log.d(EglHelper + instanceId, reusing EGL);
}

if (mEglDisplay == null) {
Log.d(EglHelper + instanceId, getting new display);
/*
 * Get to the default display.
 */
mEglDisplay =
mEgl.eglGetDisplay(EGL10.EGL_DEFAULT_DISPLAY);
} else {
Log.d(EglHelper + instanceId, reusing display);
}

if (mEglConfig == null) {
Log.d(EglHelper + instanceId, getting new config);
/*
 * We can now initialize EGL for that display
 */
int[] version = new int[2];
mEgl.eglInitialize(mEglDisplay, version);
mEglConfig = mEGLConfigChooser.chooseConfig(mEgl,
mEglDisplay);
} else {
Log.d(EglHelper + instanceId, reusing config);
}

if (mEglContext == null) {
Log.d(EglHelper + instanceId, creating new context);
/*
 * Create an OpenGL ES context. This must be done only
once, an OpenGL context is a somewhat heavy object.
 */
mEglContext = mEGLContextFactory.createContext(mEgl,
mEglDisplay, mEglConfig);
if (mEglContext == null || mEglContext ==
EGL10.EGL_NO_CONTEXT) {
throw new RuntimeException(createContext failed);
}
} else {
Log.d(EglHelper + instanceId, reusing context);
}

mEglSurface = null;
}


In GLThread:

private void stopEglLocked() {
if (mHaveEgl) {
mHaveEgl = false;
mEglHelper.destroySurface();
sGLThreadManager.releaseEglSurface(this);
}
}

Basically, you don't want a finish() in there.

But we do need to finish somewhere so,

At the end of guardedRun():

} finally {
/*
 * clean-up everything...
 */
synchronized (sGLThreadManager) {
// Log.d(GLThread + getId(), Finishing.);
stopEglLocked();
mEglHelper.finish();
}
}
}


Then Finally in GLWallpaperService:

@Override
public void onDestroy() {
super.onDestroy();
mGLThread.requestExitAndWait();
}


Of course you can remove any logging you don't want.

The idea here is that we get to reuse the display and context on
orientation changes which seems to make the Droid happy.  I haven't
had a single crash since I switched to that, and I've probably
reoriented 100 times since then in testing.

I'll update the post on my blog to contain all the current code.

On Apr 6, 2:57 pm, Robert Green rbgrn@gmail.com wrote:
 By the way - things seemed good but I'm still having the occasional
 lock-up.  The last one caused the phone to lock up badly enough that I
 had to pull the battery :(

 On Apr 6, 2:18 pm, Robert Green rbgrn@gmail.com wrote:



  I'm in disbelief, but it works!  Why does that hack work?  Is it a
  previous call to eglCreateWindowSurface which returns a bad value and
  after that, cleaning up causes a bad state and the next call to create
  window surface freezes?  I don't quite understand but I guess I never
  checked the return value of that call (because it wasn't returning
  when I was having problems, but maybe it was too late then :)).

  I tested and tested and tested again and this held up against all the
  orientation changes I could possibly make.  Good work!  I'll update
  the code I posted.

  BTW - I'm still seeing the occasional:
  E/libEGL  ( 5769): eglChooseConfig:897 error 3005 (EGL_BAD_CONFIG)
  W/dalvikvm( 5769): threadid=13: thread exiting with uncaught exception
  (group=0x4001b180)
  E/AndroidRuntime( 5769): Uncaught handler: thread GLThread 7 exiting
  due to uncaught exception
  E/AndroidRuntime( 5769): java.lang.IllegalArgumentException
  E/AndroidRuntime( 5769):        at
  com.google.android.gles_jni.EGLImpl.eglGetConfigAttrib(Native Method)
  E/AndroidRuntime( 5769):        at android.opengl.EglHelper
  

Re: [android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently

2010-04-06 Thread Ralf Schneider
Thanks a lot Robert for tracking this down!
I'm planning to use the code from your web site, very soon.


2010/4/6 Robert Green rbgrn@gmail.com

 That occasional lock-up started happening constantly to me.  I messed
 around with a few things and found that the Droid really doesn't like
 to have its Display and Context destroyed all the time.

 I modified the code so that it would reuse the display and context as
 much as possible.  I looked through my GLES book and it doesn't say
 explicitly that you should always destroy them when your surface
 changes so I have to assume that it must be ok.  Even if it's not -
 this works and it wasn't working before, so I'm using it.

 Here are the code modifications:

 In EglHelper:

public void start() {
Log.d(EglHelper + instanceId, start());
if (mEgl == null) {
Log.d(EglHelper + instanceId, getting new EGL);
/*
 * Get an EGL instance
 */
mEgl = (EGL10) EGLContext.getEGL();
} else {
Log.d(EglHelper + instanceId, reusing EGL);
}

if (mEglDisplay == null) {
Log.d(EglHelper + instanceId, getting new display);
/*
 * Get to the default display.
 */
mEglDisplay =
 mEgl.eglGetDisplay(EGL10.EGL_DEFAULT_DISPLAY);
} else {
Log.d(EglHelper + instanceId, reusing display);
}

if (mEglConfig == null) {
Log.d(EglHelper + instanceId, getting new config);
/*
 * We can now initialize EGL for that display
 */
int[] version = new int[2];
mEgl.eglInitialize(mEglDisplay, version);
mEglConfig = mEGLConfigChooser.chooseConfig(mEgl,
 mEglDisplay);
} else {
Log.d(EglHelper + instanceId, reusing config);
}

if (mEglContext == null) {
Log.d(EglHelper + instanceId, creating new context);
/*
 * Create an OpenGL ES context. This must be done only
 once, an OpenGL context is a somewhat heavy object.
 */
mEglContext = mEGLContextFactory.createContext(mEgl,
 mEglDisplay, mEglConfig);
if (mEglContext == null || mEglContext ==
 EGL10.EGL_NO_CONTEXT) {
throw new RuntimeException(createContext failed);
}
} else {
Log.d(EglHelper + instanceId, reusing context);
}

mEglSurface = null;
}


 In GLThread:

private void stopEglLocked() {
if (mHaveEgl) {
mHaveEgl = false;
mEglHelper.destroySurface();
sGLThreadManager.releaseEglSurface(this);
}
}

 Basically, you don't want a finish() in there.

 But we do need to finish somewhere so,

 At the end of guardedRun():

} finally {
/*
 * clean-up everything...
 */
synchronized (sGLThreadManager) {
// Log.d(GLThread + getId(), Finishing.);
stopEglLocked();
mEglHelper.finish();
}
}
}


 Then Finally in GLWallpaperService:

@Override
public void onDestroy() {
super.onDestroy();
mGLThread.requestExitAndWait();
}


 Of course you can remove any logging you don't want.

 The idea here is that we get to reuse the display and context on
 orientation changes which seems to make the Droid happy.  I haven't
 had a single crash since I switched to that, and I've probably
 reoriented 100 times since then in testing.

 I'll update the post on my blog to contain all the current code.

 On Apr 6, 2:57 pm, Robert Green rbgrn@gmail.com wrote:
  By the way - things seemed good but I'm still having the occasional
  lock-up.  The last one caused the phone to lock up badly enough that I
  had to pull the battery :(
 
  On Apr 6, 2:18 pm, Robert Green rbgrn@gmail.com wrote:
 
 
 
   I'm in disbelief, but it works!  Why does that hack work?  Is it a
   previous call to eglCreateWindowSurface which returns a bad value and
   after that, cleaning up causes a bad state and the next call to create
   window surface freezes?  I don't quite understand but I guess I never
   checked the return value of that call (because it wasn't returning
   when I was having problems, but maybe it was too late then :)).
 
   I tested and tested and tested again and this held up against all the
   orientation changes I could possibly make.  Good work!  I'll update
   the code I posted.
 
   BTW - I'm still seeing the occasional:
   E/libEGL  ( 5769): eglChooseConfig:897 error 3005 (EGL_BAD_CONFIG)
   W/dalvikvm( 5769): threadid=13: thread exiting with uncaught exception
   (group=0x4001b180)
   E/AndroidRuntime( 5769): Uncaught handler: thread GLThread 7 exiting
   due to uncaught exception
   E/AndroidRuntime( 5769): 

[android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently

2010-04-05 Thread Robert Green
Can any of the authorities step in on this?  So far no one has found
or at least posted a solution to this problem.  It's affecting several
of the GL live wallpapers on the market right now (just look at
comments on them - many complain of freezes on Droids)

On Apr 4, 12:19 am, Robert Green rbgrn@gmail.com wrote:
 Lance,

 It does remind me of it but one of the first things I did when I
 started working on this issue was put the render/swap buffers into a
 synchronized block so that it would be guaranteed to be finished
 before any other call could interrupt/destroy the surface/etc.  I just
 double-checked and I don't believe that it's the same issue as that
 bug.

 On Apr 3, 11:17 pm, Lance Nanek lna...@gmail.com wrote:



  Reminds me of this previous issue a little, where people were working
  out ways to make GLSurfaceView wait for the rendering to stop before
  actually pausing:http://code.google.com/p/android/issues/detail?id=4283

  On Apr 3, 5:56 pm, Robert Green rbgrn@gmail.com wrote:

   I've had this reported to me by a few people using the
   GLWallpaperService code I posted.  I've been debugging this for hours
   and have so far tracked the problem down to
   egl.eglCreateWindowSurface(display, config, nativeWindow, null);

   It never returns and every notifyAll() after that results in:
   W/SharedBufferStack( 1030): waitForCondition(ReallocateCondition)
   timed out (identity=288, status=0). CPU may be pegged. trying again.

   It seems to happen when switching orientation - so when the surface is
   being destroyed/recreated and more specifically when calls to render
   the frame are being made at the same time.  If there are no render
   calls happening while switching, things seem mostly ok.  I'm debugging
   this further but I feel like a method like that should never
   deadlock.  Seems like a bug somewhere below the line to me.

   Since none of the GL init code from the shipped live wallpapers was
   posted anywhere, I have no good reference to use for how to properly
   handle the window resizing.  Clearly the code I'm using does it a
   little differently but I still feel like a deadlock like this should
   not occur.

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe, reply using remove me as the subject.


[android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently

2010-04-05 Thread unixseb
i can help you,
i'm having this issue with earth live wallpaper.
i tracked a bug in the swap function taht causes service dies, but i
was looking for this one for a long time now !

On 3 avr, 23:56, Robert Green rbgrn@gmail.com wrote:
 I've had this reported to me by a few people using the
 GLWallpaperService code I posted.  I've been debugging this for hours
 and have so far tracked the problem down to
 egl.eglCreateWindowSurface(display, config, nativeWindow, null);

 It never returns and every notifyAll() after that results in:
 W/SharedBufferStack( 1030): waitForCondition(ReallocateCondition)
 timed out (identity=288, status=0). CPU may be pegged. trying again.

 It seems to happen when switching orientation - so when the surface is
 being destroyed/recreated and more specifically when calls to render
 the frame are being made at the same time.  If there are no render
 calls happening while switching, things seem mostly ok.  I'm debugging
 this further but I feel like a method like that should never
 deadlock.  Seems like a bug somewhere below the line to me.

 Since none of the GL init code from the shipped live wallpapers was
 posted anywhere, I have no good reference to use for how to properly
 handle the window resizing.  Clearly the code I'm using does it a
 little differently but I still feel like a deadlock like this should
 not occur.

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe, reply using remove me as the subject.


[android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently

2010-04-05 Thread Robert Green
Oh, so you solved it??  What's the issue and what's the workaround?

On Apr 4, 3:33 pm, unixseb unix...@gmail.com wrote:
 i can help you,
 i'm having this issue with earth live wallpaper.
 i tracked a bug in the swap function taht causes service dies, but i
 was looking for this one for a long time now !

 On 3 avr, 23:56, Robert Green rbgrn@gmail.com wrote:



  I've had this reported to me by a few people using the
  GLWallpaperService code I posted.  I've been debugging this for hours
  and have so far tracked the problem down to
  egl.eglCreateWindowSurface(display, config, nativeWindow, null);

  It never returns and every notifyAll() after that results in:
  W/SharedBufferStack( 1030): waitForCondition(ReallocateCondition)
  timed out (identity=288, status=0). CPU may be pegged. trying again.

  It seems to happen when switching orientation - so when the surface is
  being destroyed/recreated and more specifically when calls to render
  the frame are being made at the same time.  If there are no render
  calls happening while switching, things seem mostly ok.  I'm debugging
  this further but I feel like a method like that should never
  deadlock.  Seems like a bug somewhere below the line to me.

  Since none of the GL init code from the shipped live wallpapers was
  posted anywhere, I have no good reference to use for how to properly
  handle the window resizing.  Clearly the code I'm using does it a
  little differently but I still feel like a deadlock like this should
  not occur.

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe, reply using remove me as the subject.


[android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently

2010-04-03 Thread Lance Nanek
Reminds me of this previous issue a little, where people were working
out ways to make GLSurfaceView wait for the rendering to stop before
actually pausing:
http://code.google.com/p/android/issues/detail?id=4283

On Apr 3, 5:56 pm, Robert Green rbgrn@gmail.com wrote:
 I've had this reported to me by a few people using the
 GLWallpaperService code I posted.  I've been debugging this for hours
 and have so far tracked the problem down to
 egl.eglCreateWindowSurface(display, config, nativeWindow, null);

 It never returns and every notifyAll() after that results in:
 W/SharedBufferStack( 1030): waitForCondition(ReallocateCondition)
 timed out (identity=288, status=0). CPU may be pegged. trying again.

 It seems to happen when switching orientation - so when the surface is
 being destroyed/recreated and more specifically when calls to render
 the frame are being made at the same time.  If there are no render
 calls happening while switching, things seem mostly ok.  I'm debugging
 this further but I feel like a method like that should never
 deadlock.  Seems like a bug somewhere below the line to me.

 Since none of the GL init code from the shipped live wallpapers was
 posted anywhere, I have no good reference to use for how to properly
 handle the window resizing.  Clearly the code I'm using does it a
 little differently but I still feel like a deadlock like this should
 not occur.

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe, reply using remove me as the subject.


[android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently

2010-04-03 Thread Robert Green
Lance,

It does remind me of it but one of the first things I did when I
started working on this issue was put the render/swap buffers into a
synchronized block so that it would be guaranteed to be finished
before any other call could interrupt/destroy the surface/etc.  I just
double-checked and I don't believe that it's the same issue as that
bug.

On Apr 3, 11:17 pm, Lance Nanek lna...@gmail.com wrote:
 Reminds me of this previous issue a little, where people were working
 out ways to make GLSurfaceView wait for the rendering to stop before
 actually pausing:http://code.google.com/p/android/issues/detail?id=4283

 On Apr 3, 5:56 pm, Robert Green rbgrn@gmail.com wrote:



  I've had this reported to me by a few people using the
  GLWallpaperService code I posted.  I've been debugging this for hours
  and have so far tracked the problem down to
  egl.eglCreateWindowSurface(display, config, nativeWindow, null);

  It never returns and every notifyAll() after that results in:
  W/SharedBufferStack( 1030): waitForCondition(ReallocateCondition)
  timed out (identity=288, status=0). CPU may be pegged. trying again.

  It seems to happen when switching orientation - so when the surface is
  being destroyed/recreated and more specifically when calls to render
  the frame are being made at the same time.  If there are no render
  calls happening while switching, things seem mostly ok.  I'm debugging
  this further but I feel like a method like that should never
  deadlock.  Seems like a bug somewhere below the line to me.

  Since none of the GL init code from the shipped live wallpapers was
  posted anywhere, I have no good reference to use for how to properly
  handle the window resizing.  Clearly the code I'm using does it a
  little differently but I still feel like a deadlock like this should
  not occur.

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe, reply using remove me as the subject.


[android-developers] Re: Droid 2.1?

2009-12-28 Thread theSmith
Not to burst your bubble, but my apps have seen the Google Nexus One
and 2.1 for about a month now (found them looking through my Flurry
stats).

As for the Droid build part, well I guess we we're all expecting it to
come eventually.  Any one heard of an official release date?

On Dec 28, 12:48 pm, Maps.Huge.Info (Maps API Guru)
cor...@gmail.com wrote:
 I saw this as an agent today:

 Mozilla/5.0 (Linux; U; Android 2.1; en-us; Droid Build/ERD72)
 AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/
 530.17

 -John Coryat

 Radar Now!

 What Zip Code?

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en


Re: [android-developers] Re: Droid 2.1?

2009-12-28 Thread Abdul Mateen
Exactly , My application also sees 2.1. I can confirm it with Flurry stats
also...

On Mon, Dec 28, 2009 at 2:25 PM, theSmith chris.smith...@gmail.com wrote:

 Not to burst your bubble, but my apps have seen the Google Nexus One
 and 2.1 for about a month now (found them looking through my Flurry
 stats).

 As for the Droid build part, well I guess we we're all expecting it to
 come eventually.  Any one heard of an official release date?

 On Dec 28, 12:48 pm, Maps.Huge.Info (Maps API Guru)
 cor...@gmail.com wrote:
  I saw this as an agent today:
 
  Mozilla/5.0 (Linux; U; Android 2.1; en-us; Droid Build/ERD72)
  AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/
  530.17
 
  -John Coryat
 
  Radar Now!
 
  What Zip Code?

 --
 You received this message because you are subscribed to the Google
 Groups Android Developers group.
 To post to this group, send email to android-developers@googlegroups.com
 To unsubscribe from this group, send email to
 android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/android-developers?hl=en


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Droid 2.1?

2009-12-28 Thread Maps.Huge.Info (Maps API Guru)
I've seen Nexus already, today was the first time I saw Droid with
2.1. Maybe a test device?

-John Coryat

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en


[android-developers] Re: Droid 2.1?

2009-12-28 Thread pcm2a
They ported the Nexus 2.1 build to the droid weeks ago over on
alldroid.

On Dec 28, 5:25 pm, Maps.Huge.Info (Maps API Guru)
cor...@gmail.com wrote:
 I've seen Nexus already, today was the first time I saw Droid with
 2.1. Maybe a test device?

 -John Coryat

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en