Can any of the authorities step in on this? So far no one has found or at least posted a solution to this problem. It's affecting several of the GL live wallpapers on the market right now (just look at comments on them - many complain of freezes on Droids)
On Apr 4, 12:19 am, Robert Green <rbgrn....@gmail.com> wrote: > Lance, > > It does remind me of it but one of the first things I did when I > started working on this issue was put the render/swap buffers into a > synchronized block so that it would be guaranteed to be finished > before any other call could interrupt/destroy the surface/etc. I just > double-checked and I don't believe that it's the same issue as that > bug. > > On Apr 3, 11:17 pm, Lance Nanek <lna...@gmail.com> wrote: > > > > > Reminds me of this previous issue a little, where people were working > > out ways to make GLSurfaceView wait for the rendering to stop before > > actually pausing:http://code.google.com/p/android/issues/detail?id=4283 > > > On Apr 3, 5:56 pm, Robert Green <rbgrn....@gmail.com> wrote: > > > > I've had this reported to me by a few people using the > > > GLWallpaperService code I posted. I've been debugging this for hours > > > and have so far tracked the problem down to > > > egl.eglCreateWindowSurface(display, config, nativeWindow, null); > > > > It never returns and every notifyAll() after that results in: > > > W/SharedBufferStack( 1030): waitForCondition(ReallocateCondition) > > > timed out (identity=288, status=0). CPU may be pegged. trying again. > > > > It seems to happen when switching orientation - so when the surface is > > > being destroyed/recreated and more specifically when calls to render > > > the frame are being made at the same time. If there are no render > > > calls happening while switching, things seem mostly ok. I'm debugging > > > this further but I feel like a method like that should never > > > deadlock. Seems like a bug somewhere below the line to me. > > > > Since none of the GL init code from the shipped live wallpapers was > > > posted anywhere, I have no good reference to use for how to properly > > > handle the window resizing. Clearly the code I'm using does it a > > > little differently but I still feel like a deadlock like this should > > > not occur. -- 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 To unsubscribe, reply using "remove me" as the subject.
