Sorry to spam so many replies into this thread here... I just went and tested a couple of my wallpapers on the G2, since I've been getting new and strange reports about them. One that was NOT using glFinish seemed to behave okay, but the other that was using it was locking up every single time upon switching from portrait to landscape. I used aLogCat to view the log and this is what was going on:
W/SharedBufferStack(21310): waitForCondition(LockCondition) timed out (identity=2376, status=0). CPU may be pegged. trying again. W/SharedBufferStack(21310): waitForCondition(LockCondition) timed out (identity=2376, status=0). CPU may be pegged. trying again. W/SharedBufferStack(21310): waitForCondition(LockCondition) timed out (identity=2376, status=0). CPU may be pegged. trying again. So, maybe starting with the G2 HTC's made this non-fatal? This happened consistently upon switching from portrait to landscape. Why the one that wasn't using glFinish is immune I'm not sure, maybe they fixed things for the common case (of glFinish not being called) so now glFinish causes problems? On Oct 2, 12:25 pm, Jeremy Statz <jst...@gmail.com> wrote: > I'm not mixing Native in with anything either, straight Java is enough > trouble as is. :P > > I noticed a definitely framerate hit with glFinish as well, but I'd > rather suffer through that than have it forcibly lock up and reboot > people's phones. The worst thing is everybody but HTC seems just fine > either way. I really don't want to end up with a setting that says > "Check this if you have an HTC handset". > > After updating a few things I'm less sold on glFinish actually fixing > the problem. In particular I'm starting to get e-mails from people > who just bought a G2, and those seem to be a whole new raft of random > stuff happening. The most recent EVO update introduced flickering on > the bottom half of the screen, which I thought glFinish fixed, but it > doesn't sound like it was a 100% fix. It might just come down to the > framerate being slower in that case. > > That said, maybe it means SwapInterval is a sensible thing to try, so > I'll give it a shot. > > On Oct 2, 12:04 pm, Leigh McRae <leigh.mc...@lonedwarfgames.com> > wrote: > > > > > > > > > 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> > > ... > > 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
