That said, I just sat down to test that, and eglSwapInterval doesn't appear to be supported on Android, at least I don't see it in either EGL10 or EGL11.
On Oct 2, 3:06 pm, Jeremy Statz <jst...@gmail.com> wrote: > Back in the day glSwapInterval is what you'd use to synchronize with a > CRT's refresh rate. Setting it to one basically means that > swapBuffers wouldn't happen until the next display refresh. I'd > thought it was dead and buried, but this appears to indicate > otherwise:http://www.khronos.org/opengles/sdk/1.1/docs/man/eglSwapInterval.xml > > On a LCD screen presumably this means it'll clamp to 60Hz intervals > when swapping the buffers, so you don't get a buffer being swapped > halfway through a screen refresh. > > On Oct 2, 2:50 pm, Robert Green <rbgrn....@gmail.com> wrote: > > > > > > > > > I actually am adding a "safe mode" setting to the game that people can > > use if it's freezing on their device. I can't have it on all the time > > or the game really is unplayably slow on the first gen phones and it > > never seems to lock up on those - just snapdragons. > > > What are you guys talking about with the swap interval? Is that a > > framebuffer thing and if so, where do you handle it? > > > Thanks > > > 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 > > ... > > 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
