Wednesday, March 6, 2013

Re: [android-developers] Re: how to tell why Activity.onPause() is called



W dniu środa, 6 marca 2013 10:24:29 UTC+1 użytkownik latimerius napisał:
On Wed, Mar 6, 2013 at 7:48 AM, a1 <arc...@gmail.com> wrote:

My minSdk is 7.  Preserving GL context is a hint.  You call it and pray it works.  See the official docs at http://developer.android.com/reference/android/opengl/GLSurfaceView.html#setPreserveEGLContextOnPause(boolean)

It's just works - EGL is only allowed to dispose context on power management events, OS may terminate application process if user navigate away but that's it. Anyway if you really want to play nice you can simply reaload everything when you catch EGL_CONTEXT_LOST.

Please read the documentation I linked to - it's just a couple of lines, and clear and well-written too.  For your reading comfort, here's the key sentence:

"Whether the EGL context is actually preserved or not depends upon whether the Android device that the program is running on can support an arbitrary number of EGL contexts or not."
But did you bother to read actual sources? This policy is enforced by hack in GLSurfaceView itself (there is a static ThreadManager that keep track of all rendering thread and if device properties file has limited GL context property set preserve on pause will be ignored, if you use your own implementation you will always preserve context on pause and all devices with GL ES 2.0 (> 90% of all android devices) are required to support multiple context.
 
You're right that in EGL spec, the only reason for EGL_CONTEXT_LOST is a power management event but that's just wishful thinking unfortunately.  (BTW the whole EGL implementation on Android conforms to the spec only very roughly at best.) 
 
I mean if it works for you use it by all means - I'm just saying you cannot *rely* on it working, and personally I'm not comfortable to go down that way (especially since when it does *not* work on an end user machine you'll unlikely to get clear reproducible symptoms - no crash stack etc., just "doesn't work" type of reports).
It's not wishful thinking, this behavior is define by EGL specification, this is also how android works, anyway that was just an advice, so you are welcome to do whatever you wish.
 
 
if you are targeting older version simply back-port (or use one of existing back-ports eg. the one from Replica Island).

That's a solution with its own set of problems.  Check some of the comments in the RI version.  In fact, I highly doubt it would work well across the spectrum of today's Android hardware.
Why, current GLSurfaceView implementation is based on the one from RI.

Actually, it's the other way around:

Yeah, but maybe you should check dates:
Replica Island - 2009
ICS - 2011
 

Well the RI version does have HW-specific hacks, check its source.

Workarounds - of course, when you are writing GL dependent code there will be workarounds, because opengl implementation has bugs (like ardeno 3xx shader compiler with buffer overruns, or mali-400 crashing when glDrawArray was called with VBO bound, or infamous deadlock in ardeno-200).
 
But the point is moot anyway, see above.  While it's true that the older versions of the shipping GLSurfaceView were too eager to drop contexts, even if you fix that you apparently still cannot guarantee when context can or cannot be lost.  Which is due to lower-level software or hardware, things out of our control.
I can guarantee that on GL ES 2.0 capable GPUs context will never be lost.
 
--
Bart

--
--
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.
 
 

No comments:

Post a Comment