Re: [android-developers] Re: OpenGL lockups in 2.2

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 McRae
www.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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en