[android-developers] Re: Alternative to GLWallpaperService, OpenGL Live Wallpaper
I'm also looking into an alternative to Robert Green's method, as GLWallpaperService is segfaulting on me when setting the LWP to wallpaper. The source of RenderScript and RenderScriptGL is here: http://www.google.com/codesearch/p?hl=en#uX1GffpyOZk/graphics/java/android/renderscript/RenderScript.javaq=android.renderscript%20RenderScriptGL%20RenderScriptGLd=4 Looks like they are using native code to do the GL rendering. The nexus LWP code doesn't do much. I suspect all their drawing routines are embedded in the native. On Oct 14, 2:08 pm, Mark Guerra markfgue...@gmail.com wrote: .. I started to study the Live Wallpapers from the Android Source (http:// android.git.kernel.org/?p=platform/packages/wallpapers/ Basic.git;a=tree;f=src/com/android/wallpaper;hb=HEAD) but they seem to use RenderScriptGL, which is a non-public API at this time. I should look further into it to figure out how these wallpapers work, but as of right now I don't understand how they get their GL10 object to draw with. I also looked into Robert Green's GLWallpaperService. Btw, thanks go to Robert for all his hard work. A few projects use this method, and it works for them. Still, there are some bugs to be worked out as Robert has mentioned. I'm not sure whether Robert is maintaining it or if he moved on to bigger and better things. In any case, it seems weird that using his code would be the *only* way to create an OpenGL Live wallpaper. -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Alternative to GLWallpaperService, OpenGL Live Wallpaper
No, I've just got it logging the frame time. When running GLSurfaceView my frame period is 16ms, and 33ms when using the code under live wallpaper (both my version and Robert Green's version). The update code is SIMD (neon) and takes 4ms to run. When running in an application instead of live wallpaper I hit 50-60 fps pretty consistent, and when running in live wallpaper (same code) about 25-30 fps. I have done this with a simple clear and still see the same thing, I feel like I'm only getting in to update every other frame when under live wallpaper. On Oct 15, 6:28 pm, Adam Hammer adamhamm...@gmail.com wrote: I should also say, my LWP breaks 30fps with opengl with that code. I got a report in my comments that it holds at 40fps on some phones. I only get about 31 with the fps counter enabled, but GC because of stringbuilder to show the FPS string slows things from about 40 down to 30 when you actually show the counter. If you have GC going on, you might have a similar problem, maybe GC is what is causing your frame limit. Adam On Oct 15, 8:15 am, mr.winky mr0wi...@gmail.com wrote: Yes, I have verified with an opengl app under GLSurfaceView that I can get 60 fps. I havent been able to successfully adapt, beyond what Robert Green has posted, the GLSurfaceView to work for live wallpaper without the 30fps barrier. Is there someone out there that has solved this? On Oct 15, 6:54 am, Lance Nanek lna...@gmail.com wrote: Did you lookup the usual refresh rate, which is indeed 60FPS, or did you check the specific number for your phone? I know from my own testing that the HTC Evo 4G cannot go above 30FPS in OpenGL, for example. Chris Pruett mentioned one of the XPeria devices doing similar, running at 30FPS, even when he draws a scene with nothing in it (http://code.google.com/events/io/2010/sessions/writing-real-time-game... ). I'm just pointing out that you may actually have one of these rarer crippled phone models rather than a software issue. On Oct 13, 1:56 am, mr.winky mr0wi...@gmail.com wrote: I've been using theGLWallpaperServiceas posted by Robert Green (http://www.rbgrn.net/content/354-glsurfaceview-adapted-3d-live- wallpapers), which has worked so far for the live wallpapers but I'm hitting a wall when it comes to performance. The GL code is executing at the expected speed when swapping (about 14ms after the swap occurs), but there seems to be an extreme overhead with the wallpaper code of 33ms. For example, if I was to implement a basic live wallpaper that only called gl.glClearColor and nothing else, the maximum framerate I can achieve is 30fps (33ms), which is far lower than it should be. Now the phone refresh rate is 16ms, from what I have read, so I could understand hitting a wall at 60 fps. The question is if there is an alternative way out there? I tried naively using the GLSurfaceView with no luck and am looking for suggestions from those who may have encountered this issue or know of a solution. I have been googling but all posts send me back to the above site from Robert Green as the only way to do this, and I have had no luck finding a live wallpaper sample from the SDK that uses OpenGL while they state that you have access to OpenGL from here: http://developer.android.com/resources/articles/live-wallpapers.html I tried searching for the code for the bundled live wallpapers with no luck, if anyone could throw me a link to one of the wallpapers that uses OpenGL that would more than enough for me to figure it out (if a different method is used ;)).- Hide quoted text - - Show quoted text -- Hide quoted text - - Show quoted text - -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Alternative to GLWallpaperService, OpenGL Live Wallpaper
A couple comments -- You can profile any process with the adb shell am command. Run the command without arguments to get its help text. There is nothing about live wallpapers that intrinsically limits their speed. They get their own surface that they draw directly into like any other window, and are not artificially limited in frame rate. There is of course some other stuff happening -- more compositing because another application is on top, so if you are being limited by the fill rate of the GPU then that could have an impact (though on the other hand on some devices compositing is done with the 2d blitter instead of OpenGL so it wouldn't matter). On Sat, Oct 16, 2010 at 1:41 AM, mr.winky mr0wi...@gmail.com wrote: No, I've just got it logging the frame time. When running GLSurfaceView my frame period is 16ms, and 33ms when using the code under live wallpaper (both my version and Robert Green's version). The update code is SIMD (neon) and takes 4ms to run. When running in an application instead of live wallpaper I hit 50-60 fps pretty consistent, and when running in live wallpaper (same code) about 25-30 fps. I have done this with a simple clear and still see the same thing, I feel like I'm only getting in to update every other frame when under live wallpaper. On Oct 15, 6:28 pm, Adam Hammer adamhamm...@gmail.com wrote: I should also say, my LWP breaks 30fps with opengl with that code. I got a report in my comments that it holds at 40fps on some phones. I only get about 31 with the fps counter enabled, but GC because of stringbuilder to show the FPS string slows things from about 40 down to 30 when you actually show the counter. If you have GC going on, you might have a similar problem, maybe GC is what is causing your frame limit. Adam On Oct 15, 8:15 am, mr.winky mr0wi...@gmail.com wrote: Yes, I have verified with an opengl app under GLSurfaceView that I can get 60 fps. I havent been able to successfully adapt, beyond what Robert Green has posted, the GLSurfaceView to work for live wallpaper without the 30fps barrier. Is there someone out there that has solved this? On Oct 15, 6:54 am, Lance Nanek lna...@gmail.com wrote: Did you lookup the usual refresh rate, which is indeed 60FPS, or did you check the specific number for your phone? I know from my own testing that the HTC Evo 4G cannot go above 30FPS in OpenGL, for example. Chris Pruett mentioned one of the XPeria devices doing similar, running at 30FPS, even when he draws a scene with nothing in it ( http://code.google.com/events/io/2010/sessions/writing-real-time-game... ). I'm just pointing out that you may actually have one of these rarer crippled phone models rather than a software issue. On Oct 13, 1:56 am, mr.winky mr0wi...@gmail.com wrote: I've been using theGLWallpaperServiceas posted by Robert Green (http://www.rbgrn.net/content/354-glsurfaceview-adapted-3d-live- wallpapers), which has worked so far for the live wallpapers but I'm hitting a wall when it comes to performance. The GL code is executing at the expected speed when swapping (about 14ms after the swap occurs), but there seems to be an extreme overhead with the wallpaper code of 33ms. For example, if I was to implement a basic live wallpaper that only called gl.glClearColor and nothing else, the maximum framerate I can achieve is 30fps (33ms), which is far lower than it should be. Now the phone refresh rate is 16ms, from what I have read, so I could understand hitting a wall at 60 fps. The question is if there is an alternative way out there? I tried naively using the GLSurfaceView with no luck and am looking for suggestions from those who may have encountered this issue or know of a solution. I have been googling but all posts send me back to the above site from Robert Green as the only way to do this, and I have had no luck finding a live wallpaper sample from the SDK that uses OpenGL while they state that you have access to OpenGL from here: http://developer.android.com/resources/articles/live-wallpapers.html I tried searching for the code for the bundled live wallpapers with no luck, if anyone could throw me a link to one of the wallpapers that uses OpenGL that would more than enough for me to figure it out (if a different method is used ;)).- Hide quoted text - - Show quoted text -- Hide quoted text - - Show quoted text - -- 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+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at
Re: [android-developers] Re: Alternative to GLWallpaperService, OpenGL Live Wallpaper
I can't help with how to use OpenGL, I was just pointing out something a number of apps are doing that is likely to break in the future. On Wed, Oct 13, 2010 at 7:05 AM, mr.winky mr0wi...@gmail.com wrote: Thats fine, but you didnt answer the original question which was. What is the right way to do this? You say its supported on your website but offer no clue as to how to do it the correct way. Is what Robert Green posted the right way to go about it or is there another method. If there is, could you please point me in that direction Diane, and if its something google has overlooked, then just tell me. On Oct 13, 3:16 am, Robert Green rbgrn@gmail.com wrote: It was originally a submission for android master is why it is in that namespace :) Yes, if you use it (and be aware that it does NOT reset the gl context on orientation changes so do not reload vram content like normal or at least make sure to delete first) you will definitely want to put it in your own package/namespace. FYI - it doesn't delete the context because for some unknown reason many phones like to hard freeze right in eglMakeDisplayCurrent with the SharedBuffer timed out problem. Leaving the context in tact worked around it for some phones but there are other issues on other phones as well. On Oct 13, 1:43 am, Dianne Hackborn hack...@android.com wrote: Note that code is very broken -- it is putting a class in the android namespace, which it is not allowed to do. PLEASE change this to a valid namespace before using it. You are likely to break shortly if you don't. Thanks. On Tue, Oct 12, 2010 at 10:56 PM, mr.winky mr0wi...@gmail.com wrote: I've been using the GLWallpaperService as posted by Robert Green (http://www.rbgrn.net/content/354-glsurfaceview-adapted-3d-live- wallpapers), which has worked so far for the live wallpapers but I'm hitting a wall when it comes to performance. The GL code is executing at the expected speed when swapping (about 14ms after the swap occurs), but there seems to be an extreme overhead with the wallpaper code of 33ms. For example, if I was to implement a basic live wallpaper that only called gl.glClearColor and nothing else, the maximum framerate I can achieve is 30fps (33ms), which is far lower than it should be. Now the phone refresh rate is 16ms, from what I have read, so I could understand hitting a wall at 60 fps. The question is if there is an alternative way out there? I tried naively using the GLSurfaceView with no luck and am looking for suggestions from those who may have encountered this issue or know of a solution. I have been googling but all posts send me back to the above site from Robert Green as the only way to do this, and I have had no luck finding a live wallpaper sample from the SDK that uses OpenGL while they state that you have access to OpenGL from here: http://developer.android.com/resources/articles/live-wallpapers.html I tried searching for the code for the bundled live wallpapers with no luck, if anyone could throw me a link to one of the wallpapers that uses OpenGL that would more than enough for me to figure it out (if a different method is used ;)). -- 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+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.comandroid-developers%2Bunsubs cr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them.- Hide quoted text - - Show quoted text - -- 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+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android
[android-developers] Re: Alternative to GLWallpaperService, OpenGL Live Wallpaper
Did you lookup the usual refresh rate, which is indeed 60FPS, or did you check the specific number for your phone? I know from my own testing that the HTC Evo 4G cannot go above 30FPS in OpenGL, for example. Chris Pruett mentioned one of the XPeria devices doing similar, running at 30FPS, even when he draws a scene with nothing in it ( http://code.google.com/events/io/2010/sessions/writing-real-time-games-android.html ). I'm just pointing out that you may actually have one of these rarer crippled phone models rather than a software issue. On Oct 13, 1:56 am, mr.winky mr0wi...@gmail.com wrote: I've been using the GLWallpaperService as posted by Robert Green (http://www.rbgrn.net/content/354-glsurfaceview-adapted-3d-live- wallpapers), which has worked so far for the live wallpapers but I'm hitting a wall when it comes to performance. The GL code is executing at the expected speed when swapping (about 14ms after the swap occurs), but there seems to be an extreme overhead with the wallpaper code of 33ms. For example, if I was to implement a basic live wallpaper that only called gl.glClearColor and nothing else, the maximum framerate I can achieve is 30fps (33ms), which is far lower than it should be. Now the phone refresh rate is 16ms, from what I have read, so I could understand hitting a wall at 60 fps. The question is if there is an alternative way out there? I tried naively using the GLSurfaceView with no luck and am looking for suggestions from those who may have encountered this issue or know of a solution. I have been googling but all posts send me back to the above site from Robert Green as the only way to do this, and I have had no luck finding a live wallpaper sample from the SDK that uses OpenGL while they state that you have access to OpenGL from here: http://developer.android.com/resources/articles/live-wallpapers.html I tried searching for the code for the bundled live wallpapers with no luck, if anyone could throw me a link to one of the wallpapers that uses OpenGL that would more than enough for me to figure it out (if a different method is used ;)). -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Alternative to GLWallpaperService, OpenGL Live Wallpaper
Yes, I have verified with an opengl app under GLSurfaceView that I can get 60 fps. I havent been able to successfully adapt, beyond what Robert Green has posted, the GLSurfaceView to work for live wallpaper without the 30fps barrier. Is there someone out there that has solved this? On Oct 15, 6:54 am, Lance Nanek lna...@gmail.com wrote: Did you lookup the usual refresh rate, which is indeed 60FPS, or did you check the specific number for your phone? I know from my own testing that the HTC Evo 4G cannot go above 30FPS in OpenGL, for example. Chris Pruett mentioned one of the XPeria devices doing similar, running at 30FPS, even when he draws a scene with nothing in it (http://code.google.com/events/io/2010/sessions/writing-real-time-game... ). I'm just pointing out that you may actually have one of these rarer crippled phone models rather than a software issue. On Oct 13, 1:56 am, mr.winky mr0wi...@gmail.com wrote: I've been using theGLWallpaperServiceas posted by Robert Green (http://www.rbgrn.net/content/354-glsurfaceview-adapted-3d-live- wallpapers), which has worked so far for the live wallpapers but I'm hitting a wall when it comes to performance. The GL code is executing at the expected speed when swapping (about 14ms after the swap occurs), but there seems to be an extreme overhead with the wallpaper code of 33ms. For example, if I was to implement a basic live wallpaper that only called gl.glClearColor and nothing else, the maximum framerate I can achieve is 30fps (33ms), which is far lower than it should be. Now the phone refresh rate is 16ms, from what I have read, so I could understand hitting a wall at 60 fps. The question is if there is an alternative way out there? I tried naively using the GLSurfaceView with no luck and am looking for suggestions from those who may have encountered this issue or know of a solution. I have been googling but all posts send me back to the above site from Robert Green as the only way to do this, and I have had no luck finding a live wallpaper sample from the SDK that uses OpenGL while they state that you have access to OpenGL from here: http://developer.android.com/resources/articles/live-wallpapers.html I tried searching for the code for the bundled live wallpapers with no luck, if anyone could throw me a link to one of the wallpapers that uses OpenGL that would more than enough for me to figure it out (if a different method is used ;)).- Hide quoted text - - Show quoted text - -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Alternative to GLWallpaperService, OpenGL Live Wallpaper
The code I posted is mostly just a refactored GLSurfaceView from 2.1 Master. It shouldn't perform differently unless something deeper down is limiting. On Oct 15, 10:15 am, mr.winky mr0wi...@gmail.com wrote: Yes, I have verified with an opengl app under GLSurfaceView that I can get 60 fps. I havent been able to successfully adapt, beyond what Robert Green has posted, the GLSurfaceView to work for live wallpaper without the 30fps barrier. Is there someone out there that has solved this? On Oct 15, 6:54 am, Lance Nanek lna...@gmail.com wrote: Did you lookup the usual refresh rate, which is indeed 60FPS, or did you check the specific number for your phone? I know from my own testing that the HTC Evo 4G cannot go above 30FPS in OpenGL, for example. Chris Pruett mentioned one of the XPeria devices doing similar, running at 30FPS, even when he draws a scene with nothing in it (http://code.google.com/events/io/2010/sessions/writing-real-time-game... ). I'm just pointing out that you may actually have one of these rarer crippled phone models rather than a software issue. On Oct 13, 1:56 am, mr.winky mr0wi...@gmail.com wrote: I've been using theGLWallpaperServiceas posted by Robert Green (http://www.rbgrn.net/content/354-glsurfaceview-adapted-3d-live- wallpapers), which has worked so far for the live wallpapers but I'm hitting a wall when it comes to performance. The GL code is executing at the expected speed when swapping (about 14ms after the swap occurs), but there seems to be an extreme overhead with the wallpaper code of 33ms. For example, if I was to implement a basic live wallpaper that only called gl.glClearColor and nothing else, the maximum framerate I can achieve is 30fps (33ms), which is far lower than it should be. Now the phone refresh rate is 16ms, from what I have read, so I could understand hitting a wall at 60 fps. The question is if there is an alternative way out there? I tried naively using the GLSurfaceView with no luck and am looking for suggestions from those who may have encountered this issue or know of a solution. I have been googling but all posts send me back to the above site from Robert Green as the only way to do this, and I have had no luck finding a live wallpaper sample from the SDK that uses OpenGL while they state that you have access to OpenGL from here: http://developer.android.com/resources/articles/live-wallpapers.html I tried searching for the code for the bundled live wallpapers with no luck, if anyone could throw me a link to one of the wallpapers that uses OpenGL that would more than enough for me to figure it out (if a different method is used ;)).- Hide quoted text - - Show quoted text - -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Alternative to GLWallpaperService, OpenGL Live Wallpaper
Hmm, well live wallpapers do have icons and other UI stuff draw on top of them. That could slow things down, or the way they are used could have been written to intentionally limit their speed to preserve extra capacity for the foreground, etc.. I wonder how easy it is to debug/ traceview them to find out what's going on. It's easy to do for your own app's process, which you can set to debuggable and not have to be on an emulator or rooted phone. Live wallpapers probably run in the home process or something, though. On Oct 15, 2:27 pm, Robert Green rbgrn@gmail.com wrote: The code I posted is mostly just a refactored GLSurfaceView from 2.1 Master. It shouldn't perform differently unless something deeper down is limiting. On Oct 15, 10:15 am, mr.winky mr0wi...@gmail.com wrote: Yes, I have verified with an opengl app under GLSurfaceView that I can get 60 fps. I havent been able to successfully adapt, beyond what Robert Green has posted, the GLSurfaceView to work forlivewallpaper without the 30fps barrier. Is there someone out there that has solved this? On Oct 15, 6:54 am, Lance Nanek lna...@gmail.com wrote: Did you lookup the usual refresh rate, which is indeed 60FPS, or did you check the specific number for your phone? I know from my own testing that the HTC Evo 4G cannot go above 30FPS in OpenGL, for example. Chris Pruett mentioned one of the XPeria devices doing similar, running at 30FPS, even when he draws a scene with nothing in it (http://code.google.com/events/io/2010/sessions/writing-real-time-game... ). I'm just pointing out that you may actually have one of these rarer crippled phone models rather than a software issue. On Oct 13, 1:56 am, mr.winky mr0wi...@gmail.com wrote: I've been using theGLWallpaperServiceas posted by Robert Green (http://www.rbgrn.net/content/354-glsurfaceview-adapted-3d-live- wallpapers), which has worked so far for thelivewallpapers but I'm hitting a wall when it comes to performance. The GL code is executing at the expected speed when swapping (about 14ms after the swap occurs), but there seems to be an extreme overhead with thewallpaper code of 33ms. For example, if I was to implement a basiclivewallpaperthat only called gl.glClearColor and nothing else, the maximum framerate I can achieve is 30fps (33ms), which is far lower than it should be. Now the phone refresh rate is 16ms, from what I have read, so I could understand hitting a wall at 60 fps. The question is if there is an alternative way out there? I tried naively using the GLSurfaceView with no luck and am looking for suggestions from those who may have encountered this issue or know of a solution. I have been googling but all posts send me back to the above site from Robert Green as the only way to do this, and I have had no luck finding alivewallpapersample from the SDK that uses OpenGL while they state that you have access to OpenGL from here: http://developer.android.com/resources/articles/live-wallpapers.html I tried searching for the code for the bundledlivewallpapers with no luck, if anyone could throw me a link to one of the wallpapers that uses OpenGL that would more than enough for me to figure it out (if a different method is used ;)).- Hide quoted text - - Show quoted text - -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Alternative to GLWallpaperService, OpenGL Live Wallpaper
Don't know, but I have been googling and have found this is a common problem for 3D among the different vendors. On Oct 15, 11:27 am, Robert Green rbgrn@gmail.com wrote: The code I posted is mostly just a refactored GLSurfaceView from 2.1 Master. It shouldn't perform differently unless something deeper down is limiting. On Oct 15, 10:15 am, mr.winky mr0wi...@gmail.com wrote: Yes, I have verified with an opengl app under GLSurfaceView that I can get 60 fps. I havent been able to successfully adapt, beyond what Robert Green has posted, the GLSurfaceView to work for live wallpaper without the 30fps barrier. Is there someone out there that has solved this? On Oct 15, 6:54 am, Lance Nanek lna...@gmail.com wrote: Did you lookup the usual refresh rate, which is indeed 60FPS, or did you check the specific number for your phone? I know from my own testing that the HTC Evo 4G cannot go above 30FPS in OpenGL, for example. Chris Pruett mentioned one of the XPeria devices doing similar, running at 30FPS, even when he draws a scene with nothing in it (http://code.google.com/events/io/2010/sessions/writing-real-time-game... ). I'm just pointing out that you may actually have one of these rarer crippled phone models rather than a software issue. On Oct 13, 1:56 am, mr.winky mr0wi...@gmail.com wrote: I've been using theGLWallpaperServiceas posted by Robert Green (http://www.rbgrn.net/content/354-glsurfaceview-adapted-3d-live- wallpapers), which has worked so far for the live wallpapers but I'm hitting a wall when it comes to performance. The GL code is executing at the expected speed when swapping (about 14ms after the swap occurs), but there seems to be an extreme overhead with the wallpaper code of 33ms. For example, if I was to implement a basic live wallpaper that only called gl.glClearColor and nothing else, the maximum framerate I can achieve is 30fps (33ms), which is far lower than it should be. Now the phone refresh rate is 16ms, from what I have read, so I could understand hitting a wall at 60 fps. The question is if there is an alternative way out there? I tried naively using the GLSurfaceView with no luck and am looking for suggestions from those who may have encountered this issue or know of a solution. I have been googling but all posts send me back to the above site from Robert Green as the only way to do this, and I have had no luck finding a live wallpaper sample from the SDK that uses OpenGL while they state that you have access to OpenGL from here: http://developer.android.com/resources/articles/live-wallpapers.html I tried searching for the code for the bundled live wallpapers with no luck, if anyone could throw me a link to one of the wallpapers that uses OpenGL that would more than enough for me to figure it out (if a different method is used ;)).- Hide quoted text - - Show quoted text - -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Alternative to GLWallpaperService, OpenGL Live Wallpaper
The proper way currently would be the way the GlWallpaperService does it, get a egl context and handle everything yourself. It really doesn't have that much of a performance hit, I use the same code in a action that I do in a lwp using that class as a wrapper and I get about 75% the performance of the activity that doesn't use it at all. Considering that the LWP is running in the background I kind of expect at least a 20% hit just because, so there is maybe 5% performance hit from using that code. Adam On Oct 13, 7:05 am, mr.winky mr0wi...@gmail.com wrote: Thats fine, but you didnt answer the original question which was. What is the right way to do this? You say its supported on your website but offer no clue as to how to do it the correct way. Is what Robert Green posted the right way to go about it or is there another method. If there is, could you please point me in that direction Diane, and if its something google has overlooked, then just tell me. On Oct 13, 3:16 am, Robert Green rbgrn@gmail.com wrote: It was originally a submission for android master is why it is in that namespace :) Yes, if you use it (and be aware that it does NOT reset the gl context on orientation changes so do not reload vram content like normal or at least make sure to delete first) you will definitely want to put it in your own package/namespace. FYI - it doesn't delete the context because for some unknown reason many phones like to hard freeze right in eglMakeDisplayCurrent with the SharedBuffer timed out problem. Leaving the context in tact worked around it for some phones but there are other issues on other phones as well. On Oct 13, 1:43 am, Dianne Hackborn hack...@android.com wrote: Note that code is very broken -- it is putting a class in the android namespace, which it is not allowed to do. PLEASE change this to a valid namespace before using it. You are likely to break shortly if you don't. Thanks. On Tue, Oct 12, 2010 at 10:56 PM, mr.winky mr0wi...@gmail.com wrote: I've been using the GLWallpaperService as posted by Robert Green (http://www.rbgrn.net/content/354-glsurfaceview-adapted-3d-live- wallpapers), which has worked so far for the live wallpapers but I'm hitting a wall when it comes to performance. The GL code is executing at the expected speed when swapping (about 14ms after the swap occurs), but there seems to be an extreme overhead with the wallpaper code of 33ms. For example, if I was to implement a basic live wallpaper that only called gl.glClearColor and nothing else, the maximum framerate I can achieve is 30fps (33ms), which is far lower than it should be. Now the phone refresh rate is 16ms, from what I have read, so I could understand hitting a wall at 60 fps. The question is if there is an alternative way out there? I tried naively using the GLSurfaceView with no luck and am looking for suggestions from those who may have encountered this issue or know of a solution. I have been googling but all posts send me back to the above site from Robert Green as the only way to do this, and I have had no luck finding a live wallpaper sample from the SDK that uses OpenGL while they state that you have access to OpenGL from here: http://developer.android.com/resources/articles/live-wallpapers.html I tried searching for the code for the bundled live wallpapers with no luck, if anyone could throw me a link to one of the wallpapers that uses OpenGL that would more than enough for me to figure it out (if a different method is used ;)). -- 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+unsubscr...@googlegroups.comandroid-developers%2Bunsubs cr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them.- Hide quoted text - - Show quoted text - -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Alternative to GLWallpaperService, OpenGL Live Wallpaper
I should also say, my LWP breaks 30fps with opengl with that code. I got a report in my comments that it holds at 40fps on some phones. I only get about 31 with the fps counter enabled, but GC because of stringbuilder to show the FPS string slows things from about 40 down to 30 when you actually show the counter. If you have GC going on, you might have a similar problem, maybe GC is what is causing your frame limit. Adam On Oct 15, 8:15 am, mr.winky mr0wi...@gmail.com wrote: Yes, I have verified with an opengl app under GLSurfaceView that I can get 60 fps. I havent been able to successfully adapt, beyond what Robert Green has posted, the GLSurfaceView to work for live wallpaper without the 30fps barrier. Is there someone out there that has solved this? On Oct 15, 6:54 am, Lance Nanek lna...@gmail.com wrote: Did you lookup the usual refresh rate, which is indeed 60FPS, or did you check the specific number for your phone? I know from my own testing that the HTC Evo 4G cannot go above 30FPS in OpenGL, for example. Chris Pruett mentioned one of the XPeria devices doing similar, running at 30FPS, even when he draws a scene with nothing in it (http://code.google.com/events/io/2010/sessions/writing-real-time-game... ). I'm just pointing out that you may actually have one of these rarer crippled phone models rather than a software issue. On Oct 13, 1:56 am, mr.winky mr0wi...@gmail.com wrote: I've been using theGLWallpaperServiceas posted by Robert Green (http://www.rbgrn.net/content/354-glsurfaceview-adapted-3d-live- wallpapers), which has worked so far for the live wallpapers but I'm hitting a wall when it comes to performance. The GL code is executing at the expected speed when swapping (about 14ms after the swap occurs), but there seems to be an extreme overhead with the wallpaper code of 33ms. For example, if I was to implement a basic live wallpaper that only called gl.glClearColor and nothing else, the maximum framerate I can achieve is 30fps (33ms), which is far lower than it should be. Now the phone refresh rate is 16ms, from what I have read, so I could understand hitting a wall at 60 fps. The question is if there is an alternative way out there? I tried naively using the GLSurfaceView with no luck and am looking for suggestions from those who may have encountered this issue or know of a solution. I have been googling but all posts send me back to the above site from Robert Green as the only way to do this, and I have had no luck finding a live wallpaper sample from the SDK that uses OpenGL while they state that you have access to OpenGL from here: http://developer.android.com/resources/articles/live-wallpapers.html I tried searching for the code for the bundled live wallpapers with no luck, if anyone could throw me a link to one of the wallpapers that uses OpenGL that would more than enough for me to figure it out (if a different method is used ;)).- Hide quoted text - - Show quoted text - -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Alternative to GLWallpaperService, OpenGL Live Wallpaper
I am also working on a 3D wallpaper, and would like to know the correct way to implement an OpenGL-powered live wallpaper. This is a problem I have wrestled with on and off for a few weeks now. The Android.com article (http://developer.android.com/resources/ articles/live-wallpapers.html) seems to suggest that getting a GL10 reference for a Live Wallpaper would be no big deal, but to me it's non-obvious. So far I've tried a few approaches: I had followed the the Cube example (http://developer.android.com/ resources/samples/CubeLiveWallpaper/index.html) but the Canvas I get from that code is not backed by OpenGL. That is, calls to myCanvasInstance.getGL() return null. So to get that a GL10, I think something has to be changed along the way to initialize the Canvas using OpenGL. I am still unsure how to make this change, I probably need to read more. I started to study the Live Wallpapers from the Android Source (http:// android.git.kernel.org/?p=platform/packages/wallpapers/ Basic.git;a=tree;f=src/com/android/wallpaper;hb=HEAD) but they seem to use RenderScriptGL, which is a non-public API at this time. I should look further into it to figure out how these wallpapers work, but as of right now I don't understand how they get their GL10 object to draw with. I also looked into Robert Green's GLWallpaperService. Btw, thanks go to Robert for all his hard work. A few projects use this method, and it works for them. Still, there are some bugs to be worked out as Robert has mentioned. I'm not sure whether Robert is maintaining it or if he moved on to bigger and better things. In any case, it seems weird that using his code would be the *only* way to create an OpenGL Live wallpaper. So what is the recommended, safe way to get a GL10 object to perform the drawing for a Live Wallpaper? On Oct 13, 10:05 am, mr.winky mr0wi...@gmail.com wrote: Thats fine, but you didnt answer the original question which was. What is the right way to do this? You say its supported on your website but offer no clue as to how to do it the correct way. Is what Robert Green posted the right way to go about it or is there another method. If there is, could you please point me in that direction Diane, and if its something google has overlooked, then just tell me. On Oct 13, 3:16 am, Robert Green rbgrn@gmail.com wrote: It was originally a submission for android master is why it is in that namespace :) Yes, if you use it (and be aware that it does NOT reset the gl context on orientation changes so do not reload vram content like normal or at least make sure to delete first) you will definitely want to put it in your own package/namespace. FYI - it doesn't delete the context because for some unknown reason many phones like to hard freeze right in eglMakeDisplayCurrent with the SharedBuffer timed out problem. Leaving the context in tact worked around it for some phones but there are other issues on other phones as well. On Oct 13, 1:43 am, Dianne Hackborn hack...@android.com wrote: Note that code is very broken -- it is putting a class in the android namespace, which it is not allowed to do. PLEASE change this to a valid namespace before using it. You are likely to break shortly if you don't. Thanks. On Tue, Oct 12, 2010 at 10:56 PM, mr.winky mr0wi...@gmail.com wrote: I've been using the GLWallpaperService as posted by Robert Green (http://www.rbgrn.net/content/354-glsurfaceview-adapted-3d-live- wallpapers), which has worked so far for the live wallpapers but I'm hitting a wall when it comes to performance. The GL code is executing at the expected speed when swapping (about 14ms after the swap occurs), but there seems to be an extreme overhead with the wallpaper code of 33ms. For example, if I was to implement a basic live wallpaper that only called gl.glClearColor and nothing else, the maximum framerate I can achieve is 30fps (33ms), which is far lower than it should be. Now the phone refresh rate is 16ms, from what I have read, so I could understand hitting a wall at 60 fps. The question is if there is an alternative way out there? I tried naively using the GLSurfaceView with no luck and am looking for suggestions from those who may have encountered this issue or know of a solution. I have been googling but all posts send me back to the above site from Robert Green as the only way to do this, and I have had no luck finding a live wallpaper sample from the SDK that uses OpenGL while they state that you have access to OpenGL from here: http://developer.android.com/resources/articles/live-wallpapers.html I tried searching for the code for the bundled live wallpapers with no luck, if anyone could throw me a link to one of the wallpapers that uses OpenGL that would more than enough for me to figure it out (if a different method is used ;)). -- You received this
[android-developers] Re: Alternative to GLWallpaperService, OpenGL Live Wallpaper
It was originally a submission for android master is why it is in that namespace :) Yes, if you use it (and be aware that it does NOT reset the gl context on orientation changes so do not reload vram content like normal or at least make sure to delete first) you will definitely want to put it in your own package/namespace. FYI - it doesn't delete the context because for some unknown reason many phones like to hard freeze right in eglMakeDisplayCurrent with the SharedBuffer timed out problem. Leaving the context in tact worked around it for some phones but there are other issues on other phones as well. On Oct 13, 1:43 am, Dianne Hackborn hack...@android.com wrote: Note that code is very broken -- it is putting a class in the android namespace, which it is not allowed to do. PLEASE change this to a valid namespace before using it. You are likely to break shortly if you don't. Thanks. On Tue, Oct 12, 2010 at 10:56 PM, mr.winky mr0wi...@gmail.com wrote: I've been using the GLWallpaperService as posted by Robert Green (http://www.rbgrn.net/content/354-glsurfaceview-adapted-3d-live- wallpapers), which has worked so far for the live wallpapers but I'm hitting a wall when it comes to performance. The GL code is executing at the expected speed when swapping (about 14ms after the swap occurs), but there seems to be an extreme overhead with the wallpaper code of 33ms. For example, if I was to implement a basic live wallpaper that only called gl.glClearColor and nothing else, the maximum framerate I can achieve is 30fps (33ms), which is far lower than it should be. Now the phone refresh rate is 16ms, from what I have read, so I could understand hitting a wall at 60 fps. The question is if there is an alternative way out there? I tried naively using the GLSurfaceView with no luck and am looking for suggestions from those who may have encountered this issue or know of a solution. I have been googling but all posts send me back to the above site from Robert Green as the only way to do this, and I have had no luck finding a live wallpaper sample from the SDK that uses OpenGL while they state that you have access to OpenGL from here: http://developer.android.com/resources/articles/live-wallpapers.html I tried searching for the code for the bundled live wallpapers with no luck, if anyone could throw me a link to one of the wallpapers that uses OpenGL that would more than enough for me to figure it out (if a different method is used ;)). -- 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+unsubscr...@googlegroups.comandroid-developers%2Bunsubs cr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Alternative to GLWallpaperService, OpenGL Live Wallpaper
Thats fine, but you didnt answer the original question which was. What is the right way to do this? You say its supported on your website but offer no clue as to how to do it the correct way. Is what Robert Green posted the right way to go about it or is there another method. If there is, could you please point me in that direction Diane, and if its something google has overlooked, then just tell me. On Oct 13, 3:16 am, Robert Green rbgrn@gmail.com wrote: It was originally a submission for android master is why it is in that namespace :) Yes, if you use it (and be aware that it does NOT reset the gl context on orientation changes so do not reload vram content like normal or at least make sure to delete first) you will definitely want to put it in your own package/namespace. FYI - it doesn't delete the context because for some unknown reason many phones like to hard freeze right in eglMakeDisplayCurrent with the SharedBuffer timed out problem. Leaving the context in tact worked around it for some phones but there are other issues on other phones as well. On Oct 13, 1:43 am, Dianne Hackborn hack...@android.com wrote: Note that code is very broken -- it is putting a class in the android namespace, which it is not allowed to do. PLEASE change this to a valid namespace before using it. You are likely to break shortly if you don't. Thanks. On Tue, Oct 12, 2010 at 10:56 PM, mr.winky mr0wi...@gmail.com wrote: I've been using the GLWallpaperService as posted by Robert Green (http://www.rbgrn.net/content/354-glsurfaceview-adapted-3d-live- wallpapers), which has worked so far for the live wallpapers but I'm hitting a wall when it comes to performance. The GL code is executing at the expected speed when swapping (about 14ms after the swap occurs), but there seems to be an extreme overhead with the wallpaper code of 33ms. For example, if I was to implement a basic live wallpaper that only called gl.glClearColor and nothing else, the maximum framerate I can achieve is 30fps (33ms), which is far lower than it should be. Now the phone refresh rate is 16ms, from what I have read, so I could understand hitting a wall at 60 fps. The question is if there is an alternative way out there? I tried naively using the GLSurfaceView with no luck and am looking for suggestions from those who may have encountered this issue or know of a solution. I have been googling but all posts send me back to the above site from Robert Green as the only way to do this, and I have had no luck finding a live wallpaper sample from the SDK that uses OpenGL while they state that you have access to OpenGL from here: http://developer.android.com/resources/articles/live-wallpapers.html I tried searching for the code for the bundled live wallpapers with no luck, if anyone could throw me a link to one of the wallpapers that uses OpenGL that would more than enough for me to figure it out (if a different method is used ;)). -- 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+unsubscr...@googlegroups.comandroid-developers%2Bunsubs cr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them.- Hide quoted text - - Show quoted text - -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
