You say you don't see why anyone would use it, but then your own words give a pretty good description of when to use GLSurfaceView: when you don't care about making your code less portable, and don't need the "control taken away from you".
And by "less portable" you must mean having in mind to port to non- Android platforms. But if your application is Android specific anyway, then this is not a consideration. There will be lots of OpenGL applications out there. Just give it time to develop. GLSurfaceView is a HUGE improvement over the JME way of supporting OpenGL. On Sep 15, 5:25 pm, Leigh McRae <leigh.mc...@lonedwarfgames.com> wrote: > I don't use GLSurfaceView and I am not really sure why anyone would > use it for anything other than a demo. It makes your code less portable > and takes control away from you. > > With that said, I do get people with HTC complaining about freezes. So > it would seem that it's not a GLSurfaceView problem. > > On 9/14/2010 8:38 PM, timedilation 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 > > -- > Leigh McRaewww.lonedwarfgames.com -- 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
