for 1)
Within the if (needToWait()) stament block, there may be more code
than just this while(needToWait()) loop. But this is of little use if
this if statement has no 'else' clause. If there is indeed no else
clause, you could remove the 'if' statement all together. Maybe this
is just a left-over of some older code...?
for 2)
I wouldn't know the answer. I don't have the code handy.
for 3)
Indeed, this is not absolutely necessary. But the code just plays
nice. If an app is paused, it just tries to clean up as much as
possible so that other apps have a bit more resource.
for 4)
If your activity can be instantiated more than one time in your app,
then this is a valid safeguard.
The 'onCreate' of one activity could be called *after* the 'onDestroy'
of the other. You don't want to have 2 rendering-threads writing to
the same SurfaceView, even if is only briefly. This semaphore prevents
that by having the new rendering thread wait until the old one
finishes.
However, if you declare your activity that it can never be
instantiated more than once, this is moot.
On Apr 3, 11:18 am, "samurai00...@gmail.com" <samurai00...@gmail.com>
wrote:
> Hi everybody. This is my first post in the group, I hope not the
> last :) .
>
> I am working in an OpenGL application, and was analyzing the GLThread
> code in ApiDemos in order to define the work loop in my app. I have
> some questions about:
>
> 1/ In the fragment:
>
> if(needToWait()) {
> while (needToWait()) {
> wait();
> }
> }
>
> , why the if statement? I guess it could be related with some
> synchronization issue, but I am not able to find any scenario where it
> is necessary. I think that
>
> while (needToWait()) {
> wait()
> }
>
> would be enough.
>
> 2/ I think the member mContextLost is unnecesary. It is set to false
> in the GlThread.surfaceCreated() method, at the same time that
> mHasSurface is set to true. It is never set to true in all the code.
> It is only read at needToWait(), in a logical 'or' operation with !
> mHasSurface. I think mHasSurface is enough for the job, am I losing
> anything?
>
> 3/ Why is mEglHelper.finish() called when mPaused is true (this is,
> when the onPaused() callback in the ---Activity was called)? The
> lifecycle of Activity specifies that onPaused() is called when the
> activity is not at foreground. I understand that rendering is blocked
> in wait() in this situation, but is it really necessary releasing the
> EGL objects and recover them later?
>
> 4/ The run() method explains the use of sEglSemaphore in this
> comment:
> /*
> * When the android framework launches a second instance of
> * an activity, the new instance's onCreate() method may be
> * called before the first instance returns from onDestroy().
> *
> * This semaphore ensures that only one instance at a time
> * accesses EGL.
> */
>
> EGL and GL are considered exclusive access resources? I understand
> than the GPU is, but what's the problem in having different EGL and GL
> contexts in different threads and processes?
>
> Thank you and best regards,
>
> David A. Velasco
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
