Maybe set swap interval. I have to say I feel your pain as Android is
starting to feel like PC when it comes to graphics drivers.
On 10/1/2010 9:03 PM, Robert Green wrote:
Update - I just tested with eglWaitGL right before swapBuffers and I
got the same nasty performance hit as glFinish.
Any other ideas?
On Oct 1, 7:43 pm, Robert Green<rbgrn....@gmail.com> wrote:
I'm not mixing native with my context, but I get lots of reports of
freezing and have seen it on my Nexus One running both 2.1 and 2.2.
I'm just trying to find a solution to it.
On Oct 1, 7:04 pm, Leigh McRae<leigh.mc...@lonedwarfgames.com> wrote:
I would never call glFinish unless I was reading a buffer back. I
would also never call glFlush. Swapping the buffers will do this. When
I was writing drivers it was common for glFlush to be a NOP.
With that said, if you're mixing native with your context use the
eglWait functions. I know eglWaitGL says it's the same as glFinish but
I think the driver has a more clearer picture as to what is going on.
On 10/1/2010 7:43 PM, Robert Green wrote:
After more testing it's apparent that glFinish is causing nearly
double the frame time and it's not my code causing the issue.
Do you think adding glFlush() will do anything useful? I did that on
my first 3D game and no one's ever complained about it freezing.
On Oct 1, 6:12 pm, Robert Green<rbgrn....@gmail.com> wrote:
Bad news... My testing shows a very significant performance hit from
doing this.
Nexus One went from 40fps without ending on glFinish down to 20-27.
G1 went from 30fps down to about 5-10.
This is not good. I can't just put that in and call it fixed or it'll
make the game unplayable on low end phones. I'll do some more testing
and see if it's my threading causing problems but I have a bad feeling
that it's not.
On Sep 30, 3:30 pm, timedilation<udayan.k...@gmail.com> wrote:
Jeremy, Glad to note that is has so far worked out for you.
Leigh, to your point, I also tested this with an explicit call to
eglWaitGL() function in my own version of GLSurfaceView (basically
this call was added just before the eglSwapBuffer() call). This also
fixed thefreezingin my case. I just resorted to using glFinish()
because that way I didn't have to use my own version of GLSurfaceView.
So if Google changed their GLSurfaceView in the next release, my code
will not be affected much.
When I mentioned this to a Google developer advocate and he said that
this still needs to be fixed in the OS since it is an OS level bug.
eglSwapBuffers() called glFlush() internally anyways but it ends up
getting deadlocked once in a while on some of these devices we have
seen. Explicitly calling eglWaitGL() or glFinish() in the renderloop
*before* the eglSwapBuffers() appears to have fixed this issue in many
(if not all) cases. I still have users reporting to me that their
phonesfreezingeven with the latest update, albeit much less
frequently.
Let's hope for Google to fix this once and for all in their next
release.
On Sep 30, 2:26 pm, Leigh McRae<leigh.mc...@lonedwarfgames.com>
wrote:
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 thefreezingin 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, thefreezingseems 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 thefreezingstarts 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 thefreezing- 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
NOfreezingthere 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:
...
read more ยป
--
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
