Thanks for your answers.
I have a new doubt. Why does the synchronized block in guardedRun
finish() before the GL rendering? I think some 'dangerous' scenarios
could happen. For example:
1. 'GLThread' thread runs up to 'if (changed)' statement, with changed
== 'true'; then 'GLThread' leaves the CPU.
2. 'main' thread takes the CPU and decides to destroy the Surface
object managed by GLSurfaceView; it calls surfaceDestroyed() method,
that sets hasSurface to false without problem (synchronized block is
free). Then continues until effectively destroying the Surface.
3. 'GLThread' goes back into CPU, and runs 'gl = (GL10)
mEglHelper.createSurface(mHolder);', where mHolder 'gives access' to
the destroyed Surface.
Is not this a problem?
This kind of scenarios would be impossible if the synchronized block
covered all the code in the while(!mDone) loop. Why is not being
applied?
Thanks in advance.
On 3 abr, 19:53, Streets Of Boston <flyingdutc...@gmail.com> wrote:
> 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 theGLThread
> > 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 theGlThread.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
-~----------~----~----~----~------~----~------~--~---
