Here's a crashlog.
It happened on n1 after a rotation.
Looks like the swap function is called with a wrong arg.
04/08/2010 09:30:00 [DEBUG] EglHelperSLWP(465) start()
04/08/2010 09:30:00 [DEBUG] EglHelperSLWP(465) getting new EGL
04/08/2010 09:30:00 [DEBUG] EglHelperSLWP(465) getting new display
What's up with those 1281s?
On Apr 8, 2:53 am, seb boyart unix...@gmail.com wrote:
Here's a crashlog.
It happened on n1 after a rotation.
Looks like the swap function is called with a wrong arg.
04/08/2010 09:30:00 [DEBUG] EglHelperSLWP(465) start()
04/08/2010 09:30:00 [DEBUG]
i can't tell you if my code works for the droid (i dont own one) but
it help fixing issues on the N1.
anyway i still have issues, sometimes it looks like i have 2 opengl
surfaces swapping from each other after a resume.
i'm gonna implement your modifications and tell you the effect on the
N1
i'm currently using the code on your blog, i have an issue on N1, when
the orientation change, the surfacechanged function of the rendrerer
isn't called, so i can't reset the frustum to the correct window size.
i guess it's around the following code, i'm trying to fix it :
That's strange..
First of all, how are you getting orientation changes on an N1? I
never found a way to get it to do that.
I tested my latest code on www.rbgrn.net on both the N1 and Droid and
both seem to be working well now. It includes your wait-hack and my
updates.
On Apr 7, 3:57 pm,
I use helixlauncher2 to rotate the desktop on n1.
Le 7 avr. 2010 23:01, Robert Green rbgrn@gmail.com a écrit :
That's strange..
First of all, how are you getting orientation changes on an N1? I
never found a way to get it to do that.
I tested my latest code on www.rbgrn.net on both the N1
I didn't know about helixlauncher2. It's cool!
Now I can navigate the home screen just with the thumb. That never worked
reliable for me with the stock homescreen of the N1.
And everything is smooth. Feels like an iphone...
2010/4/7 seb boyart unix...@gmail.com
I use helixlauncher2 to rotate
forget it, your code is fine, it call the surfacechanged right, passing good
values for width and height.
for obvious reasons, my sphere isn't restreched after a rotation (it does
approx 5% of the time only), but all initialization is done
in surfacechanged using passed width and height, it worked
have a look at the svn repository on code.google.com/project/earth-
live-wallpaper
the hack int the glwallpaperservice class avoid some crashes with
screen rotation on droids.
On 5 avr, 20:24, Robert Green rbgrn@gmail.com wrote:
Oh, so you solved it?? What's the issue and what's the
I'm also interested in this topic. I got an 404 on the link: This seems to
work:
http://code.google.com/p/earth-live-wallpaper/
Thank you for sharing your code!
2010/4/6 unixseb unix...@gmail.com
have a look at the svn repository on code.google.com/project/earth-
live-wallpaper
Assuming I correctly identified the code that unixseb uses as the
workaround/fix for orientation changes on Droid in Live Wallpaper with
OpenGL, the following code is the same with the exception of
recursion:
public EGLSurface createWindowSurface(EGL10 egl, EGLDisplay
display, EGLConfig
I'm in disbelief, but it works! Why does that hack work? Is it a
previous call to eglCreateWindowSurface which returns a bad value and
after that, cleaning up causes a bad state and the next call to create
window surface freezes? I don't quite understand but I guess I never
checked the return
By the way - things seemed good but I'm still having the occasional
lock-up. The last one caused the phone to lock up badly enough that I
had to pull the battery :(
On Apr 6, 2:18 pm, Robert Green rbgrn@gmail.com wrote:
I'm in disbelief, but it works! Why does that hack work? Is it a
That occasional lock-up started happening constantly to me. I messed
around with a few things and found that the Droid really doesn't like
to have its Display and Context destroyed all the time.
I modified the code so that it would reuse the display and context as
much as possible. I looked
Thanks a lot Robert for tracking this down!
I'm planning to use the code from your web site, very soon.
2010/4/6 Robert Green rbgrn@gmail.com
That occasional lock-up started happening constantly to me. I messed
around with a few things and found that the Droid really doesn't like
to
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
i can help you,
i'm having this issue with earth live wallpaper.
i tracked a bug in the swap function taht causes service dies, but i
was looking for this one for a long time now !
On 3 avr, 23:56, Robert Green rbgrn@gmail.com wrote:
I've had this reported to me by a few people using the
Oh, so you solved it?? What's the issue and what's the workaround?
On Apr 4, 3:33 pm, unixseb unix...@gmail.com wrote:
i can help you,
i'm having this issue with earth live wallpaper.
i tracked a bug in the swap function taht causes service dies, but i
was looking for this one for a long
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
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
20 matches
Mail list logo
