This is not a supported use case. You can either draw with OpenGL ES 2.0 or Cavnas, but not both at the same time.
On Fri, Apr 26, 2013 at 5:13 AM, Alex Rempel <[email protected]>wrote: > 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. > > > -- Romain Guy Android framework engineer [email protected] -- -- 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.
