You might want to look into the eglWait functions that are used to
synchronize with the native rendering system.
On 9/30/2010 2:07 PM, Jeremy Statz wrote:
I've tested this extensively at this point (including a 20-hour run on
an Incredible) and I think you're right, calling glFinish() seems like
it largely fixes the problem. Wow, I'd really thought that one was
outmoded.
Related to this, the most recent EVO update was causing the
framebuffer to flicker with black squares sometimes on my wallpapers,
and calling glFinish() fixed that too. And it fixed a similar
corruption I had reported a few days ago on the Nexus one. It's the
magic HTC fixer-upper!
TimeDilation, you're my hero.
On Sep 21, 3:26 pm, timedilation<udayan.k...@gmail.com> wrote:
It was happening between 1 - 45 minutes into the app. Every single
time.
Maybe this is not a permanent fix and maybe it has just reduced the
frequency of freezings. But as I mentioned before, so far I have not
seen a single freeze since I made that change 2 days ago.
On Sep 21, 4:05 pm, Robert Green<rbgrn....@gmail.com> wrote:
And it was happening reliably before?
On Sep 21, 12:48 pm, timedilation<udayan.k...@gmail.com> wrote:
I haven't seen any freeze since making that change (I am only testing
this on the HTC Desire running 2.2)
On Sep 21, 1:32 pm, Robert Green<rbgrn....@gmail.com> wrote:
So after finishing with glFinish(), you haven't seen a freeze at all
or you just saw one now? I'm not sure what to make of the "until now"
part :)
If you really think that's making a difference, I'll try it out and
see if it makes a difference for my games as well, though I have to
play for about an hour to see it happen.
On Sep 21, 12:10 pm, timedilation<udayan.k...@gmail.com> wrote:
Not sure if the following will fix the freezing in all cases but it
appears to have fixed it in my app. I still have my fingers crossed
about it although my app hasn't frozen for a while now - even when I
let it run overnight on an HTC Desire 2.2.
I first took the source code of GLSurfaceView into my custom class and
added this line immediately before the eglSwapBuffer() call in the
EGLHelper class function:
mEgl.glWaitGL();
This is a blocking call that waits for all existing GL commands to be
processed before returning. With this line, the freezing seems to have
stopped.
I then realized that the glFinish() function does the same thing. So I
went back to using the built-in GLSurfaceView and added the glFinish()
call at the very end of my renderer.onDrawFrame() function. This had
the same effect and I haven't seen a freeze until now. I suspect this
call is just making the loop wait explicitly for all GL commands to be
processed before rendering again. I took a look in the profiler and
this call did not add any extra overhead (likely because the
eglSwapBuffers() is also a blocking call and does the same thing -
except that it freezes randomly).
If the freezing starts again, I will update this post.
Hope this works for you all out there too.
On Sep 17, 7:46 am, String<sterling.ud...@googlemail.com> wrote:
It's not all OpenGL implementations, that's for sure. I have 2 apps
with OpenGL live wallpapers; one has had the lockup problem, the other
hasn't. Architecturally, they're very similar - I based the later one
off the earlier. It was by pursuing the differences (like changing
textures mid-stream, as I discussed in an earlier post) that I've been
able to stop the lockups so far.
String
On Sep 17, 4:26 am, timedilation<udayan.k...@gmail.com> wrote:
I have played games like Winds of Steel for hours on my HTC desire.
Surely they must be using opengl as well (I think). And the FPS is
also pretty good. How's it that those games do not freeze at all? I
need to dissect those and see what calls they are making.
On Sep 15, 12:17 pm, Jeremy Statz<jst...@gmail.com> wrote:
I just let the same wallpaper run uninterrupted on a Motorola Droid
for something like 16 hours and it's still fine. I would've expected
my Incredible to have hit the problem by then. I also haven't heard
any reports of this from folks with a Galaxy S variant.
On Sep 14, 7:38 pm, timedilation<udayan.k...@gmail.com> wrote:
This appears to be an HTC specific bug. My app never freezes on the
Motorla Droid. EVER. It is very stable on the Droid and I have tested
it for about 4months without a single freeze. Interestingly though it
never froze on my G1 either. The G1 I have is the ADP1 phone I bought
directly from Google.
All other HTC phones that I have exhibit the freezing - Evo, Desire
and Nexus One (which is also from HTC I believe).
Apart from that I tested it for a month on Samsung Moment. There was
NO freezing there either.
I have been in touch with a Google developer advocate and I have
submitted the bug report to his team. They are looking into this as
well.
On Sep 14, 8:23 pm, Jeremy Statz<jst...@gmail.com> wrote:
That's my experience as well. All my log results say that there's no
loading or anything necessary -- the frame it dies on is bog standard,
with drawFrame going from beginning to end. Any loading is long since
done.
I'm currently wondering if this is an HTC driver bug. I'm going to
let this run on a Motorola Droid all night and see if it crashes. Not
sure I'm expecting it to, as my fiance has been using my wallpapers on
her Droid since forever and says she's never seen it lock and reboot
like we're describing. Is there anyone at HTC to take something like
that to, if I gather some evidence?
On Sep 14, 3:32 pm, timedilation<udayan.k...@gmail.com> wrote:
That's interesting..
Although I know for sure that all my gl* calls are happening only in
the GL thread. And this freezing happens even when I simply leave the
device (HTC Desire) running my app with zero user interaction
whatsoever. All the app renders is a scenery with a single animation.
No texture changes or geometry changes are taking place in this
scenario. But because of the animation, I have to render continuously
and this is why I have not used the Render_when_dirty approach.
I did notice that when the app freezes, my main UI thread as well as a
secondary thread (that talks to a game server) are still running and
alive. The main UI thread does register touches until a point and then
hangs while the secondary thread stays alive. I tried to send an
interrupt() to the GLThread from this secondary thread but that did
not help. The GLThread remained stuck in eglSwapBuffer();
On Sep 14, 3:42 pm, String<sterling.ud...@googlemail.com> wrote:
On Sep 13, 11:24 pm, Jeremy Statz<jst...@gmail.com> wrote:
The big problem here, in my eyes, is that this appears to
affect any OpenGL using application, and is tremendously discouraging,
to the point that people pull things off the market and avoid using
OpenGL.
I've been chasing this in a couple of my own OpenGL apps for a couple
of months as well. It's summed up well in this thread - extremely
intermittent, but extremely serious when it does happen. And I'm one
of the devs who has pulled an app from the Market as a result.
At the moment, I'm provisionally optimistic that I've worked around
the issue in my case. Given it's a race condition, I took the approach
of maximum thread-safety: I put a whole load of semaphores into my
code, added "synchronized" and "volatile" modifiers all over the
place, that sort of thing. And it seems to have been successful... I
can't be sure (because of the intermittency), but I haven't seen it
happen for a couple of weeks now.
If I had to speculate, I'd say that the problem finally went when I
synchronized some code which re-generates geometry within my OpenGL
model. I added semaphores to ensure that textures, geometry, and
rendering never happened concurrently. There's no way to know that was
the end problem, but that SEEMED to be it. If that helps anyone.
Just to reiterate, I agree that this is a serious platform-level bug
that needs to be fixed by Google. And it has gotten worse since 2.2,
although I have (rarely) seen it happen on my G1 running 1.6.
String
--
Leigh McRae
www.lonedwarfgames.com
--
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
