New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

redesigned android live wallpaper backend #306

Merged
merged 17 commits into from Mar 24, 2013

Conversation

Projects
None yet
7 participants
@jwisniewski
Contributor

jwisniewski commented Mar 18, 2013

Redesigned android lwp backend for libGDX.
All known bugs of current libGDX implementation had been fixed.
Based on libGDX 0.9.8.

Please read also msg sent to badlogicgames at gmail.com.

I have developed my own live wallpaper with help of libGDX enhanced with this code. You can track user comments and generally how it works on various devices:

True Water Free:
https://play.google.com/store/apps/details?id=com.jw.lwp.aqua.free

True Water:
https://play.google.com/store/apps/details?id=com.jw.lwp.aqua.pro


About new design of LWP backend (sorry for my not the best english..):

libGDX is based on singletons (Gdx.app etc), moreover user can implement his own singletons and it just works when libGDX is used to make desktop applications, android activities etc. Live Wallpaper backend was designed in wrong way (from libGDX point of view), this design tried to force libGDX to work in environment it was not designed to. Should be only one instance of libGDX singletons in application, but libgdx wallpapers work on many engines with many SurfaceHolders..

I just moved things to (in my opinion) right direction: I forced live wallpapers API to create environment libGDX is designed to.
Redesigned AndroidLiveWallpaperService manages all this madness linked with switching wallpaper 'engines' by itself. Rest of user application, libGDX internals etc. works normally and exactly the same as in other types of applications (there is only one instantion of ApplicationListener, AndroidGraphicsLiveWallpaper, GLSurfaceView etc). It should be possible to run any of existing libgdx apps as wallpaper now (perhaps after solving few little issues - I'm new in libGDX:)).

All lifecycle issues was resolved. With this LW backend user can switch wallpapers as fast as he want, can sleep phone in live wallpaper preview, it now runs without problems on devices on which it crashed before.
No null gl contexts inside render() method.
Much faster wallpaper loading (ex in preview)
Much faster resuming after phone was in sleep mode.
Classes duplicated for lwp backend are no longer used an can be deleted (GL..SurfaceViewLW etc).

If end developer want to implement custom application behavior in wallpaper preview, there is additional interface called AndroidWallpaperListener, he should implement it in his application listener and respond for event called when preview is opened/closed (see modified LiveWallpaper test).


What I did (technically):

  • Completely new implementation of AndroidLiveWallpaperService. There can be many engines in runtime, and any of them is linked with own SurfaceHolder on wallpaper should draw. But.. only one engine is active at specific time. Wallpaper service switches smartly between them and update GLSurfaceView to use currently active SurfaceHolder and render on it. This is transparent for rest of application, and for GLSurfaceView itself too! I just simulates events called when surface holder is lost or restored. GLSurfaceView 'think' its surface was lost and restored, but really it was just switched to another surface holder (linked with active wallpaper engine).
  • AndroidGraphicsLiveWallpaper now uses GLSurfaceView and GLSurfaceViewCapcake as original AndroidGraphics (with slight modifications). GL..SurfaceViewLW classes are deprecated, not used, and can be removed completely.
  • AndroidGraphisLiveWallpaper synchronized with current AndroidGraphics
    and AndroidGraphicsDaydream (now it is near mirror copy of original AndroidGraphics, I think you should merge this three classes in near feature before they will be resynchronized again, it shouldn't be hard to do)
  • AndroidWallpaperListener, interface that can be implemented in addition to ApplicationListener in libgdx application to autimatically add support for live wallpaper specific events
  • updated LiveWallpaper test
  • constructor in com.badlogic.gdx.graphics.Mesh - optimizations for dynamic meshes (not linked with lwp)

Modified files:

com.badlogic.gdx.backends.android.AndroidLiveWallpaper
com.badlogic.gdx.backends.android.AndroidLiveWallpaperService <- completely new implementation
com.badlogic.gdx.backends.android.AndroidGraphicsLiveWallpaper <- now uses GLSurfaceView
com.badlogic.tests.android.LiveWallpaper

com.badlogic.gdx.graphics.Mesh <- changes not linked with live wallpapers


Files no longer used:
Any files with suffixes ..LW can be removed - they aren't used by current wallpaper backend.


Added files:
com.badlogic.gdx.android.AndroidWallpaperListener <- callback allowing ApplicationListener to receive wallpaper specific events, if you don't like this solution, you could refactor it to WallpaperListener and read it as 'generic purpose wallpaper listener, currently supported only on android':)

jwisniewski added some commits Feb 15, 2013

What I did (philosophy):
libGDX is based on singletons (Gdx.app etc), moreover user can implement
his own singletons and it just works when libGDX is used to make desktop
applications, android activities etc. Live Wallpaper backend was
designed in wrong way (from libGDX point of view), this design tried to
force libGDX to work in environment it was not designed to. There should
be only one instance of libGDX singletons in application, but libgdx
wallpapers work on many engines with many SurfaceHolders..

I just moved things to (in my opinion) right direction: I forced live
wallpapers API to create environment libGDX is designed to. Redesigned
AndroidLiveWallpaperService stops all this madness linked with switching
wallpaper 'engines' by itself. Rest of user application, libGDX
internals etc. works normally and exactly the same as in other types of
applications (there is only one instantion of ApplicationListener,
AndroidGraphicsLiveWallpaper, GLSurfaceView etc). It should be possible
to run any of existing libgdx apps as wallpaper now (perhaps after
solving few little issues - I'm new in libGDX:)).

All lifecycle issues was resolved. With this LW backend user can switch
wallpapers as fast as he want, can sleep phone in live wallpaper
preview, it now runs without problems on devices on which it crashed
before. No null gl contexts inside render() method.
Much faster wallpaper loading (ex in preview)
Much faster resuming after phone was in sleep mode.
Most of code duplicated for LW backend is no longer used and can be
deleted.

If end developer want to implement custom application behavior in
wallpaper preview, there is additional interface called
AndroidWallpaperListener, he should implement it in his application
listener and respond for event called when preview is opened/closed (see
modified LiveWallpaper test).



What I did (technically):

+ Completely new implementation of AndroidLiveWallpaperService. There
can be many engines in runtime, and any of them is linked with own
SurfaceHolder on wallpaper should draw. But.. only one engine is active
at specific time. Wallpaper service switches smartly between them and
update GLSurfaceView to use currently active SurfaceHolder and render on
it. This is transparent for rest of application, and for GLSurfaceView
itself too! I just simulates events called when surface holder is lost
or restored. GLSurfaceView 'think' its surface was lost and restored,
but really it was just switched to another surface holder (linked with
active wallpaper engine).

+ AndroidGraphicsLiveWallpaper now uses GLSurfaceView and
GLSurfaceViewCapcake as original AndroidGraphics (with slight
modifications). GL..SurfaceViewLW classes are deprecated, not used, and
can be removed completely.

+ AndroidGraphisLiveWallpaper synchronized with current AndroidGraphics
and AndroidGraphicsDaydream (now it is near mirror copy of original
AndroidGraphics, I think you should merge this three classes in near
feature before they will be resynchronized again, it shouldn't be hard
to do)

+ AndroidWallpaperListener, interface that can be implemented in
addition to ApplicationListener in libgdx application to autimatically
add support for live wallpaper specific events

+ updated LiveWallpaper test
+ synchronization in AndroidGraphicsLiveWallpaper.resume
+ fixed synchronization of lifecycle methods in
AndroidGraphicsLiveWallpaper (waiting threads was notified too early and
on some devices it caused errors while rotating device in LWP
preview:
A/libc(1274): Fatal signal 11 (SIGSEGV) at 0x0000003c (code=1), thread
1291 (Thread-153)
+ more logging
+ optimized number of calls to logger (less logging! when pausing /
restoring live wallpaper - which can occur very often in contrast to
regular applications)
~ input created without help of AndroidInputFactory - it causes errors
when obfuscated because of reflection relying on plain class names
+ bugfix: "Fatal Signal 11" on some devices when rotating lwp in preview
application listener pause will not be called anymore!
@MobiDevelop

This comment has been minimized.

Show comment
Hide comment
@MobiDevelop

MobiDevelop Mar 18, 2013

Member

Cool, I merged this locally into a new branch based on master for testing. I posted a build on my site for anyone interested to test with. Since I'm not a live wallpaper person myself I'm not a good test user.

http://nexsoftware.net/uploads/gdx/libgdx-0.9.9-LWP.zip

I'm not sure about the Mesh changes so I didn't merge that.

Member

MobiDevelop commented Mar 18, 2013

Cool, I merged this locally into a new branch based on master for testing. I posted a build on my site for anyone interested to test with. Since I'm not a live wallpaper person myself I'm not a good test user.

http://nexsoftware.net/uploads/gdx/libgdx-0.9.9-LWP.zip

I'm not sure about the Mesh changes so I didn't merge that.

@bitiotic

This comment has been minimized.

Show comment
Hide comment
@bitiotic

bitiotic Mar 19, 2013

Contributor

I don't know much about Android wallpapers, so I can't really comment on the meat of the changes, but from the description it sounds great. :) I've got a bunch of minor comments and questions on what did see in the diff, but you'll need to get feedback from someone who knows more about this stuff, too.

Contributor

bitiotic commented Mar 19, 2013

I don't know much about Android wallpapers, so I can't really comment on the meat of the changes, but from the description it sounds great. :) I've got a bunch of minor comments and questions on what did see in the diff, but you'll need to get feedback from someone who knows more about this stuff, too.

AndroidLiveWallpaper app;
// jw: changed

This comment has been minimized.

@bitiotic

bitiotic Mar 19, 2013

Contributor

These "// jw:" comments are fine for now, but should probably be removed before submitting. The github pull request diff makes all of your changes quite clear, so you can just go ahead and add or delete stuff. We will know what you changed through the diff.

@bitiotic

bitiotic Mar 19, 2013

Contributor

These "// jw:" comments are fine for now, but should probably be removed before submitting. The github pull request diff makes all of your changes quite clear, so you can just go ahead and add or delete stuff. We will know what you changed through the diff.

This comment has been minimized.

@jwisniewski

jwisniewski Mar 19, 2013

Contributor

Yes, feel free to remove unnecessary comments, it just helps me to manage thinks while designing and applying my changes.

@jwisniewski

jwisniewski Mar 19, 2013

Contributor

Yes, feel free to remove unnecessary comments, it just helps me to manage thinks while designing and applying my changes.

Gdx.app.log("AndroidGraphics", "waiting for pause synchronization failed!");
if (useGL2 && checkGL20()) {
GLSurfaceView20 view = new GLSurfaceView20(context, resolutionStrategy) {
// -> specific for live wallpapers

This comment has been minimized.

@bitiotic

bitiotic Mar 19, 2013

Contributor

Its not clear what these "-> specific for live wallpapers" comments mean. This whole file contains code specific to live wallpapers, no?

@bitiotic

bitiotic Mar 19, 2013

Contributor

Its not clear what these "-> specific for live wallpapers" comments mean. This whole file contains code specific to live wallpapers, no?

This comment has been minimized.

@jwisniewski

jwisniewski Mar 19, 2013

Contributor

I had updated AndroidGraphicsLiveWallpaper class to match original AndroidGraphics as much as possible - I think in future releases all classes should be merged together:

AndroidGraphics
AndroidGraphicsLiveWallpaper
AndroidGraphicsDayream

I wanted to make it easier for you in the future. This " -> specific for live wallpapers" comments marks thinks allowing live wallpapers to work - differences between original AndroidGraphics class.

@jwisniewski

jwisniewski Mar 19, 2013

Contributor

I had updated AndroidGraphicsLiveWallpaper class to match original AndroidGraphics as much as possible - I think in future releases all classes should be merged together:

AndroidGraphics
AndroidGraphicsLiveWallpaper
AndroidGraphicsDayream

I wanted to make it easier for you in the future. This " -> specific for live wallpapers" comments marks thinks allowing live wallpapers to work - differences between original AndroidGraphics class.

// jw: old implementation, makes use of GL..SurfaceViewLW

This comment has been minimized.

@bitiotic

bitiotic Mar 19, 2013

Contributor

If this code isn't necessary anymore, I think you should just delete it. git will track the history if we ever need to look at it again.

@bitiotic

bitiotic Mar 19, 2013

Contributor

If this code isn't necessary anymore, I think you should just delete it. git will track the history if we ever need to look at it again.

private GLBaseSurfaceViewLW createGLSurfaceView (AndroidLiveWallpaper app, boolean useGL2,
ResolutionStrategy resolutionStrategy) {
// jw: synchronized with original AndroidGraphics

This comment has been minimized.

@bitiotic

bitiotic Mar 19, 2013

Contributor

If this code is getting out of synch with changes made to AndroidGraphics, perhaps the duplicate code should be factored out somewhere common to avoid this problem in the future?

@bitiotic

bitiotic Mar 19, 2013

Contributor

If this code is getting out of synch with changes made to AndroidGraphics, perhaps the duplicate code should be factored out somewhere common to avoid this problem in the future?

This comment has been minimized.

@jwisniewski

jwisniewski Mar 19, 2013

Contributor

See my previous answer to your comment. The problem is all following classes should be merged together:
AndroidGraphics
AndroidGraphicsLiveWallpaper
AndroidGraphicsDayream

It is libgdx design and its intention is probably to secure original AndroidGraphics from changes necessary to add support for somewhat experimental functionality: lwps and day dreams

@jwisniewski

jwisniewski Mar 19, 2013

Contributor

See my previous answer to your comment. The problem is all following classes should be merged together:
AndroidGraphics
AndroidGraphicsLiveWallpaper
AndroidGraphicsDayream

It is libgdx design and its intention is probably to secure original AndroidGraphics from changes necessary to add support for somewhat experimental functionality: lwps and day dreams

running = true;
resume = true;
// by jw: added synchronization, there was nothing before

This comment has been minimized.

@bitiotic

bitiotic Mar 19, 2013

Contributor

As a general rule, comments that compare the current code to previous iterations of the code are not that useful to folks who cannot see the old code, so please try and keep your comments focused on the current state of the code.

@bitiotic

bitiotic Mar 19, 2013

Contributor

As a general rule, comments that compare the current code to previous iterations of the code are not that useful to folks who cannot see the old code, so please try and keep your comments focused on the current state of the code.

This comment has been minimized.

@jwisniewski

jwisniewski Mar 19, 2013

Contributor

Sorry for this. I'm new in libGDX. I had to manage how libGDX works, how live wallpapers works, how GLSurfaceView works and how connect singleton based libGDX with many engines of android live wallpapers:)

So all this comments helps me to manage all of this, Helps me to understand what I tried and why it didn't work. I didn't deleted it yet because I'm not pretty sure I finished my work there - It still needs more tests. On top of this changes I had developed live wallpaper in OpenGL 2.0, OpenGL 1.0 is almost not tested.

@jwisniewski

jwisniewski Mar 19, 2013

Contributor

Sorry for this. I'm new in libGDX. I had to manage how libGDX works, how live wallpapers works, how GLSurfaceView works and how connect singleton based libGDX with many engines of android live wallpapers:)

So all this comments helps me to manage all of this, Helps me to understand what I tried and why it didn't work. I didn't deleted it yet because I'm not pretty sure I finished my work there - It still needs more tests. On top of this changes I had developed live wallpaper in OpenGL 2.0, OpenGL 1.0 is almost not tested.

@jwisniewski

This comment has been minimized.

Show comment
Hide comment
@jwisniewski

jwisniewski Mar 19, 2013

Contributor

I had updated pull request description with links to my own lwp that makes use of this code, so you can easily test how it works in real environment:)

Contributor

jwisniewski commented Mar 19, 2013

I had updated pull request description with links to my own lwp that makes use of this code, so you can easily test how it works in real environment:)

@atomicbrainman

This comment has been minimized.

Show comment
Hide comment
@atomicbrainman

atomicbrainman Mar 19, 2013

Thank you for the great work!

But there are multiple problems when using config with
config.useGL20 = false;

On Motorola Defy+ (Gingerbread 2.3.4) gl surface is somehow treated as cupcake during onPause and onResume:
03-19 10:02:54.280: E/AndroidRuntime(7228): at com.badlogic.gdx.backends.android.surfaceview.GLSurfaceViewCupcake.onPause(GLSurfaceViewCupcake.java:354)
03-19 10:02:54.280: E/AndroidRuntime(7228): at com.badlogic.gdx.backends.android.AndroidLiveWallpaper.onPause(AndroidLiveWallpaper.java:129)

And on emulators "offsetChange" doesn't work properly.
Could you look into that matter?

atomicbrainman commented Mar 19, 2013

Thank you for the great work!

But there are multiple problems when using config with
config.useGL20 = false;

On Motorola Defy+ (Gingerbread 2.3.4) gl surface is somehow treated as cupcake during onPause and onResume:
03-19 10:02:54.280: E/AndroidRuntime(7228): at com.badlogic.gdx.backends.android.surfaceview.GLSurfaceViewCupcake.onPause(GLSurfaceViewCupcake.java:354)
03-19 10:02:54.280: E/AndroidRuntime(7228): at com.badlogic.gdx.backends.android.AndroidLiveWallpaper.onPause(AndroidLiveWallpaper.java:129)

And on emulators "offsetChange" doesn't work properly.
Could you look into that matter?

@jwisniewski

This comment has been minimized.

Show comment
Hide comment
@jwisniewski

jwisniewski Mar 19, 2013

Contributor

It looks like GLSurfaceViewCupcake is not 1 to 1 replacement for GLSurfaceView. I will check this. The fastest possible fix is to do not use GLSurfaceViewCupcake, look at:

line 206 of AndroidGraphicsLiveWallpaper.createGLSurfaceView

You can replace GLSurfaceViewCupcake with DefaultGLSurfaceViewLW for example. But my intention was to use the same surface classes as in android backend.

"offsetChange" just redirects message from the system, maybe this problem is not linked with this lwp backend? generally offsetChange doesn't work properly on many devices.

Contributor

jwisniewski commented Mar 19, 2013

It looks like GLSurfaceViewCupcake is not 1 to 1 replacement for GLSurfaceView. I will check this. The fastest possible fix is to do not use GLSurfaceViewCupcake, look at:

line 206 of AndroidGraphicsLiveWallpaper.createGLSurfaceView

You can replace GLSurfaceViewCupcake with DefaultGLSurfaceViewLW for example. But my intention was to use the same surface classes as in android backend.

"offsetChange" just redirects message from the system, maybe this problem is not linked with this lwp backend? generally offsetChange doesn't work properly on many devices.

@atomicbrainman

This comment has been minimized.

Show comment
Hide comment
@atomicbrainman

atomicbrainman Mar 19, 2013

Forgot to mention that when set
config.useGL20 = true;
none of those problems are present. And offsetChange is working properly.

atomicbrainman commented Mar 19, 2013

Forgot to mention that when set
config.useGL20 = true;
none of those problems are present. And offsetChange is working properly.

@Opotech

This comment has been minimized.

Show comment
Hide comment
@Opotech

Opotech Mar 19, 2013

Contributor

This looks really great.

Cupcake surfaceview was originally only used for GDX GL1 on API<=4 until someone realised that it fixes the EGL_BAD_ALLOC bug http://code.google.com/p/libgdx/issues/detail?id=541 for all devices. That bug was apparently fixed in AOSP http://code.google.com/p/android/issues/detail?id=16124 aosp-mirror/platform_frameworks_base@c3fba3b which should have made it into 2.3.4+
Original GDX : https://github.com/libgdx/libgdx/blob/3bd15b5c4efe6688ea007c91a6af5d61d7688485/backends/gdx-backend-android/src/com/badlogic/gdx/backends/android/AndroidGraphics.java

In AOSP 2.2 surfaceview, they 'improved' error handling to catch more errors. Anything prior to 2.2 (I assume) is more similar to the GDX cupcake surfaceview in that it ignores any error except for context loss in swap()
see: aosp-mirror/platform_frameworks_base@04b17ab#opengl/java/android/opengl/GLSurfaceView.java

So you could probably take the latest glsurfaceview code from AOSP and modify it to ignore errors (use that for GL1 and GL2 on <API8) then just extend Android GLSurfaceview (GLSurfaceview 20) for everything else.
They moved the error checking to guardedRun() and also improved error handing and recovery also so it may be beneficial.

I could be wrong about the changes in error checking being responsible for hiding the EGL_BAD_ALLOC bug, I have not tested it.

It may also break, and bugs are hard to find in GLSurfaceview.

Contributor

Opotech commented Mar 19, 2013

This looks really great.

Cupcake surfaceview was originally only used for GDX GL1 on API<=4 until someone realised that it fixes the EGL_BAD_ALLOC bug http://code.google.com/p/libgdx/issues/detail?id=541 for all devices. That bug was apparently fixed in AOSP http://code.google.com/p/android/issues/detail?id=16124 aosp-mirror/platform_frameworks_base@c3fba3b which should have made it into 2.3.4+
Original GDX : https://github.com/libgdx/libgdx/blob/3bd15b5c4efe6688ea007c91a6af5d61d7688485/backends/gdx-backend-android/src/com/badlogic/gdx/backends/android/AndroidGraphics.java

In AOSP 2.2 surfaceview, they 'improved' error handling to catch more errors. Anything prior to 2.2 (I assume) is more similar to the GDX cupcake surfaceview in that it ignores any error except for context loss in swap()
see: aosp-mirror/platform_frameworks_base@04b17ab#opengl/java/android/opengl/GLSurfaceView.java

So you could probably take the latest glsurfaceview code from AOSP and modify it to ignore errors (use that for GL1 and GL2 on <API8) then just extend Android GLSurfaceview (GLSurfaceview 20) for everything else.
They moved the error checking to guardedRun() and also improved error handing and recovery also so it may be beneficial.

I could be wrong about the changes in error checking being responsible for hiding the EGL_BAD_ALLOC bug, I have not tested it.

It may also break, and bugs are hard to find in GLSurfaceview.

@badlogic

This comment has been minimized.

Show comment
Hide comment
@badlogic

badlogic Mar 19, 2013

Member

As Opotech said, modifying any GLSurfaceView related code is likely to break (heavily). I'd appreciate if we kept our fingers off of that :)

Member

badlogic commented Mar 19, 2013

As Opotech said, modifying any GLSurfaceView related code is likely to break (heavily). I'd appreciate if we kept our fingers off of that :)

@jwisniewski

This comment has been minimized.

Show comment
Hide comment
@jwisniewski

jwisniewski Mar 19, 2013

Contributor

"Cupcake surfaceview was originally only used for GDX GL1 on API<=4 until someone realised that it fixes the EGL_BAD_ALLOC"

I'm familiar with this bug and with http://code.google.com/p/libgdx/issues/detail?id=541.

The PROBLEM is, this bug is ACTIVE even on android 4.0+, OpenGL 2.0 when original android GLSurfaceView is used. It just needs specific conditions to occur - and I had to do something with this, because my lwp crashed on some devices. This is documented somewhere in code of this pull request. This is the main reason why I resigned from 'ApplicationListener.pause' event for live wallpapers. I just didn't find other solution to resolve this issue when OpenGL 2.0 is used.

As badlogic said - experimenting with surface view is somewhat risky. So I resigned from duplicated classes like GLSurfaceViewLW and switched live wallpaper backend to the same surfaces as used in regular android apps.

These problems with cupcake surface view and my backend should not be hard to resolve. I will try to do it as fast as possible.

Contributor

jwisniewski commented Mar 19, 2013

"Cupcake surfaceview was originally only used for GDX GL1 on API<=4 until someone realised that it fixes the EGL_BAD_ALLOC"

I'm familiar with this bug and with http://code.google.com/p/libgdx/issues/detail?id=541.

The PROBLEM is, this bug is ACTIVE even on android 4.0+, OpenGL 2.0 when original android GLSurfaceView is used. It just needs specific conditions to occur - and I had to do something with this, because my lwp crashed on some devices. This is documented somewhere in code of this pull request. This is the main reason why I resigned from 'ApplicationListener.pause' event for live wallpapers. I just didn't find other solution to resolve this issue when OpenGL 2.0 is used.

As badlogic said - experimenting with surface view is somewhat risky. So I resigned from duplicated classes like GLSurfaceViewLW and switched live wallpaper backend to the same surfaces as used in regular android apps.

These problems with cupcake surface view and my backend should not be hard to resolve. I will try to do it as fast as possible.

@acoppes

This comment has been minimized.

Show comment
Hide comment
@acoppes

acoppes Mar 22, 2013

Member

I have merged it on a local branch with latest libgdx (had to remove GLU
stuff), and it is working pretty well, at least it seems the old lwp bugs
are gone.

On Tue, Mar 19, 2013 at 12:09 PM, Jaroslaw Wisniewski <
notifications@github.com> wrote:

"Cupcake surfaceview was originally only used for GDX GL1 on API<=4 until
someone realised that it fixes the EGL_BAD_ALLOC"

I'm familiar with this bug and with
http://code.google.com/p/libgdx/issues/detail?id=541.

The PROBLEM is, this bug is ACTIVE even on android 4.0+, OpenGL 2.0 when
original android GLSurfaceView is used. It just needs specific conditions
to occur - and I had to do something with this, because my lwp crashed on
some devices. This is documented somewhere in code of this pull request.
This is the main reason why I resigned from 'ApplicationListener.pause'
event for live wallpapers. I just didn't find other solution to resolve
this issue when OpenGL 2.0 is used.

As badlogic said - experimenting with surface view is somewhat risky. So I
resigned from duplicated classes like GLSurfaceViewLW and switched live
wallpaper backend to the same surfaces as used in regular android apps.

These problems with cupcake surface view and my backend should not be hard
to resolve. I will try to do it as fast as possible.


Reply to this email directly or view it on GitHubhttps://github.com/libgdx/libgdx/pull/306#issuecomment-15120057
.

Gemserk Studios http://blog.gemserk.com

Member

acoppes commented Mar 22, 2013

I have merged it on a local branch with latest libgdx (had to remove GLU
stuff), and it is working pretty well, at least it seems the old lwp bugs
are gone.

On Tue, Mar 19, 2013 at 12:09 PM, Jaroslaw Wisniewski <
notifications@github.com> wrote:

"Cupcake surfaceview was originally only used for GDX GL1 on API<=4 until
someone realised that it fixes the EGL_BAD_ALLOC"

I'm familiar with this bug and with
http://code.google.com/p/libgdx/issues/detail?id=541.

The PROBLEM is, this bug is ACTIVE even on android 4.0+, OpenGL 2.0 when
original android GLSurfaceView is used. It just needs specific conditions
to occur - and I had to do something with this, because my lwp crashed on
some devices. This is documented somewhere in code of this pull request.
This is the main reason why I resigned from 'ApplicationListener.pause'
event for live wallpapers. I just didn't find other solution to resolve
this issue when OpenGL 2.0 is used.

As badlogic said - experimenting with surface view is somewhat risky. So I
resigned from duplicated classes like GLSurfaceViewLW and switched live
wallpaper backend to the same surfaces as used in regular android apps.

These problems with cupcake surface view and my backend should not be hard
to resolve. I will try to do it as fast as possible.


Reply to this email directly or view it on GitHubhttps://github.com/libgdx/libgdx/pull/306#issuecomment-15120057
.

Gemserk Studios http://blog.gemserk.com

@jwisniewski

This comment has been minimized.

Show comment
Hide comment
@jwisniewski

jwisniewski Mar 22, 2013

Contributor

Thanks. I just had not time in past days:/ I'm going to check this today.
I can assure that on OpenGL 2.0 all works perfectly. Users of my app do not report any related issues. Also my lwp had been approved on samsung apps.

Contributor

jwisniewski commented Mar 22, 2013

Thanks. I just had not time in past days:/ I'm going to check this today.
I can assure that on OpenGL 2.0 all works perfectly. Users of my app do not report any related issues. Also my lwp had been approved on samsung apps.

fixed support for GLSurfaceViewCupcake
Note:
I added slight modification to lifecycle of surface view in general.
I have tested it on Galaxy S and Galaxy S3, but it is not yet as heavy
tested as last implementation (by thousands of my clients on google
play and samsung apps). So this update can repair support for OpenGL
1.x, but can also destroy it on OpenGL 2.0.
@jwisniewski

This comment has been minimized.

Show comment
Hide comment
@jwisniewski

jwisniewski Mar 23, 2013

Contributor

I fixed issue with support for the GLSurfaceViewCupcake so I would be happy if you could merge this code with libgdx now:)
Also further testing is recommended as well:)

This modified lwp backend fixes all known issues with live wallpapers also it just simplifies things. It does not use duplicated surface view classes like: [..]GLSurfaceView[..]LW these files can be safely deleted.

Contributor

jwisniewski commented Mar 23, 2013

I fixed issue with support for the GLSurfaceViewCupcake so I would be happy if you could merge this code with libgdx now:)
Also further testing is recommended as well:)

This modified lwp backend fixes all known issues with live wallpapers also it just simplifies things. It does not use duplicated surface view classes like: [..]GLSurfaceView[..]LW these files can be safely deleted.

@acoppes

This comment has been minimized.

Show comment
Hide comment
@acoppes

acoppes Mar 23, 2013

Member

It works for me, I am using latest libgdx + your changes, tested on Samsung
Galaxy S1 with both OpenGL 1 and 2 and latest cyanogenmod.

On Sat, Mar 23, 2013 at 5:10 PM, Jaroslaw Wisniewski <
notifications@github.com> wrote:

I fixed issue with support for the GLSurfaceViewCupcake so I would be
happy if you could merge this code with libgdx now:)
Also further testing is recommended as well:)

This modified lwp backend fixes all known issues with live wallpapers also
it just simplifies things. It does not use duplicated surface view classes
like: [..]GLSurfaceView[..]LW these files can be safely deleted.


Reply to this email directly or view it on GitHubhttps://github.com/libgdx/libgdx/pull/306#issuecomment-15343869
.

Gemserk Studios http://blog.gemserk.com

Member

acoppes commented Mar 23, 2013

It works for me, I am using latest libgdx + your changes, tested on Samsung
Galaxy S1 with both OpenGL 1 and 2 and latest cyanogenmod.

On Sat, Mar 23, 2013 at 5:10 PM, Jaroslaw Wisniewski <
notifications@github.com> wrote:

I fixed issue with support for the GLSurfaceViewCupcake so I would be
happy if you could merge this code with libgdx now:)
Also further testing is recommended as well:)

This modified lwp backend fixes all known issues with live wallpapers also
it just simplifies things. It does not use duplicated surface view classes
like: [..]GLSurfaceView[..]LW these files can be safely deleted.


Reply to this email directly or view it on GitHubhttps://github.com/libgdx/libgdx/pull/306#issuecomment-15343869
.

Gemserk Studios http://blog.gemserk.com

@badlogic

This comment has been minimized.

Show comment
Hide comment
@badlogic

badlogic Mar 24, 2013

Member

@acoppes can you close this PR and create a new one with your merged changes? OP, let me know if that's OK for you. acoppes told me he got all the things working.

Member

badlogic commented Mar 24, 2013

@acoppes can you close this PR and create a new one with your merged changes? OP, let me know if that's OK for you. acoppes told me he got all the things working.

@acoppes

This comment has been minimized.

Show comment
Hide comment
@acoppes

acoppes Mar 24, 2013

Member

Yep.

On Sun, Mar 24, 2013 at 7:01 PM, Mario Zechner notifications@github.comwrote:

@acoppes https://github.com/acoppes can you close this PR and create a
new one with your merged changes? OP, let me know if that's OK for you.
acoppes told me he got all the things working.


Reply to this email directly or view it on GitHubhttps://github.com/libgdx/libgdx/pull/306#issuecomment-15370350
.

Gemserk Studios http://blog.gemserk.com

Member

acoppes commented Mar 24, 2013

Yep.

On Sun, Mar 24, 2013 at 7:01 PM, Mario Zechner notifications@github.comwrote:

@acoppes https://github.com/acoppes can you close this PR and create a
new one with your merged changes? OP, let me know if that's OK for you.
acoppes told me he got all the things working.


Reply to this email directly or view it on GitHubhttps://github.com/libgdx/libgdx/pull/306#issuecomment-15370350
.

Gemserk Studios http://blog.gemserk.com

@atomicbrainman

This comment has been minimized.

Show comment
Hide comment
@atomicbrainman

atomicbrainman Mar 25, 2013

Looks like all is ok now with OpenGL 1.x and 2.0. Thank you!

atomicbrainman commented Mar 25, 2013

Looks like all is ok now with OpenGL 1.x and 2.0. Thank you!

@jwisniewski

This comment has been minimized.

Show comment
Hide comment
@jwisniewski

jwisniewski Mar 25, 2013

Contributor

Thanks you too:)

Contributor

jwisniewski commented Mar 25, 2013

Thanks you too:)

@badlogic

This comment has been minimized.

Show comment
Hide comment
@badlogic

badlogic Apr 7, 2013

Member

AndroidLivewallpaperListener needs to leave the core project now!

Member

badlogic commented on bc244bf Apr 7, 2013

AndroidLivewallpaperListener needs to leave the core project now!

This comment has been minimized.

Show comment
Hide comment
@jwisniewski

jwisniewski Apr 7, 2013

Contributor

What do you think about renaming ...androind.AndroidLiveWallpaperListener to WallpaperListener? It would be more generic, even if we know that wallpapers are used only on android.

Contributor

jwisniewski replied Apr 7, 2013

What do you think about renaming ...androind.AndroidLiveWallpaperListener to WallpaperListener? It would be more generic, even if we know that wallpapers are used only on android.

This comment has been minimized.

Show comment
Hide comment
@badlogic

badlogic Apr 7, 2013

Member

No, it is Android specific and therefor should go into the Android backend.

Member

badlogic replied Apr 7, 2013

No, it is Android specific and therefor should go into the Android backend.

This comment has been minimized.

Show comment
Hide comment
@jwisniewski

jwisniewski Apr 7, 2013

Contributor
Contributor

jwisniewski replied Apr 7, 2013

This comment has been minimized.

Show comment
Hide comment
@badlogic

badlogic Apr 7, 2013

Member

I understand the issue, it boils down to having your LWP listener in the Android project instead of the main project. I think that's how it should be. If we start introducing backend specific interfaces in core, we'll end up with a mess.

Member

badlogic replied Apr 7, 2013

I understand the issue, it boils down to having your LWP listener in the Android project instead of the main project. I think that's how it should be. If we start introducing backend specific interfaces in core, we'll end up with a mess.

This comment has been minimized.

Show comment
Hide comment
@MobiDevelop

MobiDevelop Apr 7, 2013

Member

I'm going to have to agree with @badlogic on this. We don't want to be mixing backend specific stuff into core.

Member

MobiDevelop replied Apr 7, 2013

I'm going to have to agree with @badlogic on this. We don't want to be mixing backend specific stuff into core.

This comment has been minimized.

Show comment
Hide comment
@jwisniewski

jwisniewski Apr 7, 2013

Contributor

I respect your opinion. This interface was merged with libgdx due to accepting my pull request with the new live wallpapers' backend. You are free to modify this in any way. I would like to propose you how to do it, but I just do not see any better solution:/ we can back to old approach and force developers to propagate events from wallpaper service by themselves.


Below I'm trying to explain why I had added android specific interface to core lib:

If wallpaper listener will be moved to android backend, developers will be forced to include android backend libs to core projects, I mean, following structure will not be valid any more for live wallpapers:

GameProject
gdx.jar lib included

GameProjectAndroid
gdx-android-backend.jar lib included

I think, including gdx-backend-android.jar to GameProject is not better than including one small interface to core lib.
Please, notice that ApplicationListener is fragmented already – it works differently on android and desktops (resume event is never called on desktops for example). You could improve your design by extrapolating my idea of backend specific interfaces (just a poor example! To explain my idea):

ApplicationListener – events called on any backend
create
resize
render
dispose

AndroidActivityListener – events called only on android backend
pause
resume

AndroidWallpaperListener – events called only for live wallpapers
offsetChange
previewStateChange

And with such design, developers would decide what events they want to process, by adding specific interfaces:

class MyGame implements ApplicationListener, AndroidWallpaperListener

Contributor

jwisniewski replied Apr 7, 2013

I respect your opinion. This interface was merged with libgdx due to accepting my pull request with the new live wallpapers' backend. You are free to modify this in any way. I would like to propose you how to do it, but I just do not see any better solution:/ we can back to old approach and force developers to propagate events from wallpaper service by themselves.


Below I'm trying to explain why I had added android specific interface to core lib:

If wallpaper listener will be moved to android backend, developers will be forced to include android backend libs to core projects, I mean, following structure will not be valid any more for live wallpapers:

GameProject
gdx.jar lib included

GameProjectAndroid
gdx-android-backend.jar lib included

I think, including gdx-backend-android.jar to GameProject is not better than including one small interface to core lib.
Please, notice that ApplicationListener is fragmented already – it works differently on android and desktops (resume event is never called on desktops for example). You could improve your design by extrapolating my idea of backend specific interfaces (just a poor example! To explain my idea):

ApplicationListener – events called on any backend
create
resize
render
dispose

AndroidActivityListener – events called only on android backend
pause
resume

AndroidWallpaperListener – events called only for live wallpapers
offsetChange
previewStateChange

And with such design, developers would decide what events they want to process, by adding specific interfaces:

class MyGame implements ApplicationListener, AndroidWallpaperListener

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment