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