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: > > >>>>>>>>>>>> That's interesting.. > > >>>>>>>>>>>> Although I know for sure that all my gl* calls are happening > > >>>>>>>>>>>> only in > > >>>>>>>>>>>> the GL thread. And thisfreezinghappens 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, > > ... > > read more » -- 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
