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:
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
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,
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
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
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,
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
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
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
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
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
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
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
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,
14 matches
Mail list logo
