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