Hi piplz,

I filed a bug regarding the (see title) problem, but maybe someone already 
has a solution (or a soap-rope-can't-do answer) I can use.

Bug link:
http://code.google.com/p/android/issues/detail?id=54731

Bug copy:

Hello Team!

What:
Switching between rendering engine modes worked before but doesn't anymore.

Local Steps&Info:
1. is wallpaper service, rendering thread separate from UI thread
2. Start: rendering on surface with SurfaceHolder.lockCanvas and 
SurfaceHolder.unlockCanvasAndPost
3. Switch: change mode to OpenGL ES 2.0 rendering in preferences (the 
surface has gone onSurfaceInvisible at this point)
4. Tech: all surface events are handled, the unlockCanvasAndPost is called 
at least once
4. eglCreateWindowSurface(display, config, holder, attrs) throws...
...: E/libEGL(3028): EGLNativeWindowType 0x70ef9f58 already connected to 
another API
...: E/libEGL(3028): eglCreateWindowSurface:298 error 300b 
(EGL_BAD_NATIVE_WINDOW)

Bug details:
The bug occurs on 4.2.2 (tested on Nexus 10 and Motorola Droid), but it 
works perfectly fine on 2.3.6 (Nexus 1). After bug occurs the thread 
doesn't do anything (intended). Going back to wallpaper selection and 
selecting the same wallpaper goes back to same thread, waking it up with a 
new surface and then the GLES20 mode works. The consequent on-the-fly 
switch to Canvas rendering works also. The bug then occurs again on the 
switch from Canvas to GLES20 as described.

Tried workarounds:
- repeatedly trying to sleep a while in the thread and then to terminate 
and re-create the EGL context on the surface doesn't help, the error 
persists until a completely new surface comes into play


I'm not really sure if this is a bug now or if the bug was in 2.3.6 
actually not showing the aforementioned error.
If the error is valid:
- is there something else to unlock/release concerning the surface?
- can it work at all or is the new blocking behaviour intended?
- is there a way to request a new surface without restarting the activity 
(the wallpaper is hold in memory and not really kill-able by user like 
other apps leading to invalid states while this bug occurs)?

Thx,
Alex Rempel

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to