Re: [android-developers] Re: SurfaceHolder.setFormat() only working when called from the *wrong* thread?

On Fri, Aug 23, 2013 at 11:03 PM, Nobu Games <dev.nobu.games@gmail.com> wrote:

I'm not sure if I understand you correctly when exactly you set the format. It sounds too me as if you're setting it "too late", after the OpenGL ES context has been created.

Yes, it's after the context has been created (but has not yet been made current).  I believe this should be fine, NDK samples do the same (in native code - it's done using different calls there but semantics are the same), as various versions of GLSurfaceView seem to do, too.  Which makes sense to me after all, I wouldn't expect a connection between an EGL context on one hand and a pixel surface/its format on the other...

 

What I do is setting the format in the Activity's onCreate method on the UI thread before the OpenGL context is initialized and before a renderer has been set. Maybe your setFormat call is postponed in a way so you lose the OpenGL context and it forces a re-creation?

This was what I used initially but there are problems with this.  onCreate() does not know yet which EGL configs are available, nor which one of them the application will prefer.  Also, I'm not sure if lifetime of your Activity and your native window are tied - in other words, it likely could happen that the window is destroyed and recreated during a single Activity instance lifetime. (?)

 

I guess it just works for you on different devices because your call to setFormat does not actually change the format, so nothing happens. Your older 2.2 Android device may have a different default format for the surface view (such as RGB565) compared to newer devices.

I'm testing this on 3 legacy devices (I call EGL from native code on anything >9 so this Java version only concerns old devices): Desire, Galaxy S and Optimus One.  The initial format of the native window is -1 on all three.  The target format is 4 on Desire and Optimus, 1 on Galaxy (never mind the difference - it's because I just take the first decent config for now) so I'd say they all probably change formats.  It does look though like the Optimus does something differently.

I guess what I'm actually interested in is: suppose I'm running on the render thread, about to pass a native window (SurfaceHolder) to eglCreateWindowSurface().  However I notice I still need to manipulate the native window's format before that.  What is the correct way to achieve that?

 

On Friday, August 23, 2013 1:11:57 PM UTC-5, latimerius wrote:

In a testing program I'm playing with currently, I want to use setFormat() to adapt the pixel format of my surface to the chosen EGL config before I pass the surface holder to eglCreateWindowSurface().

Now, I call EGL from my render thread and I know SurfaceHolder.setFormat() is documented to have to be "called from the same thread running the SurfaceView's window", which I take to be the main thread.  To comply, I wrap my setFormat() call in a Runnable which I pass to runOnUiThread() and wait() until it's actually executed.

This works perfectly on some devices, however it gives me intermittent failures on Optimus One (with Android 2.2)  - on program start-up, three times out of four the screen is just black.  Even if start-up goes right, the first configuration change makes the screen go black.  The program still runs and no GL or EGL calls signal any errors.

Here's the weirdest part - if I omit the runOnUiThread() stuff and simply call setFormat() from my render thread, it fixes the problem and the program runs 100% solid on Optimus no matter much beating I give it - randomly pressing Home and Back while rotating the device wildly, putting it to sleep and waking it back up, the renderer always handles the native window changes correctly and renders just fine.

I'm at a loss, does anyone have an explanation?

--
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+unsubscribe@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 unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
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+unsubscribe@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 unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.