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: > >>>>>>>>>>>>>>>> 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 > > ... > > 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
