Friday, April 26, 2013

[android-developers] Switching between GLES2.0 and native Canvas rendering on the fly works in 2.3.6 but no in 4.2.2

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:

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 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
---
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 android-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

No comments:

Post a Comment