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 the freezing in 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, the freezing seems 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 the freezing starts 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 the freezing - 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 > > > > > > NO freezing there 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 this freezing happens 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, added "synchronized" and "volatile" modifiers all over > > > > > > > > > the > > > > > > > > > place, that sort of thing. And it seems to have been > > > > > > > > > successful... I > > > > > > > > > can't be sure (because of the intermittency), but I haven't > > > > > > > > > seen it > > > > > > > > > happen for a couple of weeks now. > > > > > > > > > > If I had to speculate, I'd say that the problem finally went > > > > > > > > > when I > > > > > > > > > synchronized some code which re-generates geometry within my > > > > > > > > > OpenGL > > > > > > > > > model. I added semaphores to ensure that textures, geometry, > > > > > > > > > and > > > > > > > > > rendering never happened concurrently. There's no way to know > > > > > > > > > that was > > > > > > > > > the end problem, but that SEEMED to be it. If that helps > > > > > > > > > anyone. > > > > > > > > > > Just to reiterate, I agree that this is a serious > > > > > > > > > platform-level bug > > > > > > > > > that needs to be fixed by Google. And it has gotten worse > > > > > > > > > since 2.2, > > > > > > > > > although I have (rarely) seen it happen on my G1 running 1.6. > > > > > > > > > > String -- 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
