LWP Tips/General Info
As the main culprit who goaded Erel into producing the LWP library, I feel a responsibility to chime in and spill the beans by offering some helpful information to the folks who are struggling with creating LWPs and need to know some general basics.
First things first:
Just to have said it, an animated GIF is still a GIF - that means nothing beyond the crappy 256 color limitations of the GIF format. Any app you create with GIFs being used for graphics will be limited to 256 colors. This means potentially grainy graphics - and there's nothing you'd be able to do about it. Also, the GIF format does not produce tiny file sizes, they can be VERY large, and push your app into huge bloatware territory that will have potential customers shunning it. Ever downloaded an animated GIF from the web? Notice how huge the file sizes are. Just so you know.
If you want high quality LWPs, you're going to be using JPG images only (or PNG if you need an alpha channel, but PNGs can get huge too so beware). And yes, you're probably going to be looping them in a list array using a timer unless you want to engage in some pretty complex animation programming using Java, which I'm not sure B4A is up to. I do know that Erel has clarified that you will not be using B4A to do OpenGL programming for LWPs (if you're into OpenGL programming on any accomplished level, there's a good chance that your programming skills are beyond the level of the average VB jockey who's using B4A for their chosen development platform).
All of my animations are series of export images that I create in other 2D and 3D animation software (like Flash, ToonBoom, 3DS MAX, etc). I use these products as "cheaters" to create profesional graphic content that allows me to fake high quality 3D in my apps. The tradeoff is that I'm basically making inefficient movies and looping them as LWPs instead of creating truly efficient, complex Java OpenGL animations. Oh well, the world of entertainment is nothing but a well-orchestrated universe of shortcuts, corner-cutting and lowest-common-denominator fakery. Welcome to Hollywood and the wonderful world of bloatware.
You'll probably want to use a frame rate of at least 24/second (30fps preferable for smooth motion) or it's gonna be an annoyingly jerky slideshow (unless you WANT or NEED it to be a slideshow). This is controlled using the tick value of the Live Wallpaper service. Want 30fps for a smooth animation? 1000/30 = 33, so that means a new image gets cycled with a tick value of 33. A frame rate of 24 fps means cycling a new image with a tick set to 42. And whatever animation software you use to create the series of images will need to be set at the same frame rate that you use in your LWP. Remember that.
Also know that cycling images puts a load on the processor the same way playing a movie does. Same exact thing, zero difference. As such, you will notice that this puts a bit of a performance lag on the phone when you're sliding home screens left and right. This does NOT happen when any app is launched, however, as the LWP then hibernates. This lag is not severe, but noticeable compared to non-movie, efficient, complex LWPs. No particular reason I mention this other than an FYI factoid for the sake of it.
LWP developers who write the really super high-class, complex, real Java-animated LWPs (the ones that use true 3D graphics, loads of animation code, perform beautifully smooth, and put virtually no load on the phone) criticize these types of LWPs mostly for marketing purposes, but they are correct - the type of LWP I describe above is in fact a "looping movie" that puts a recognizable (but not severe) load on the processor and battery.
If you plan on cycling images to animate your LWPs like so many of us do, fair warning: the more resolution, color and movement in your images, the bigger the files are and the more "processing bandwidth" they use. Keep your loops short enough to keep the APK file size down - live wallpapers are generally considered hideous bloatware if they exceed 9 megabytes. You can go over 10mb with just a few seconds of animated image looping! No matter what, your finished LWP should be under 10mb, and under 5mb if you're wise and took the time to find your "magic combination. All the best ones out there are very small (usually 2-5mb). You'll have to find the magic combination of frame rate, image quality, and resolution on your own to see how it works for your app. And each app can be different. When my LWPs end up being about 2-3mb, I kick the image quality or resolution up to get it up to about 5mb just for quality's sake, but only when it makes sense to do so. Good judgment is called for with these things.
As for a previous comment about the "instability" of using list arrays for animating LWPs, I strongly disagree. Every single one of my LWPs are solid as a rock using that method, and a few of my LWPs include multiple list arrays nearly 2,000 images in size (the size of the list arrays themselves, not actual image count). Read that again. If your LWP is unstable, you've done something wrong.
No, list array-driven LWPs are not perfect performance-wise, but close enough to not have anybody in my world complaining one bit - I have not heard of any instabilities or crashes from any of my customers. The only thing any of my LWPs might suffer from is if I make the mistake of choosing boring subject material or create crappy-looking graphics content.
Sorry for the epic novel, but somebody out there is gonna be happy about this. And that definitely would have included me last year.
As the main culprit who goaded Erel into producing the LWP library, I feel a responsibility to chime in and spill the beans by offering some helpful information to the folks who are struggling with creating LWPs and need to know some general basics.
First things first:
Just to have said it, an animated GIF is still a GIF - that means nothing beyond the crappy 256 color limitations of the GIF format. Any app you create with GIFs being used for graphics will be limited to 256 colors. This means potentially grainy graphics - and there's nothing you'd be able to do about it. Also, the GIF format does not produce tiny file sizes, they can be VERY large, and push your app into huge bloatware territory that will have potential customers shunning it. Ever downloaded an animated GIF from the web? Notice how huge the file sizes are. Just so you know.
If you want high quality LWPs, you're going to be using JPG images only (or PNG if you need an alpha channel, but PNGs can get huge too so beware). And yes, you're probably going to be looping them in a list array using a timer unless you want to engage in some pretty complex animation programming using Java, which I'm not sure B4A is up to. I do know that Erel has clarified that you will not be using B4A to do OpenGL programming for LWPs (if you're into OpenGL programming on any accomplished level, there's a good chance that your programming skills are beyond the level of the average VB jockey who's using B4A for their chosen development platform).
All of my animations are series of export images that I create in other 2D and 3D animation software (like Flash, ToonBoom, 3DS MAX, etc). I use these products as "cheaters" to create profesional graphic content that allows me to fake high quality 3D in my apps. The tradeoff is that I'm basically making inefficient movies and looping them as LWPs instead of creating truly efficient, complex Java OpenGL animations. Oh well, the world of entertainment is nothing but a well-orchestrated universe of shortcuts, corner-cutting and lowest-common-denominator fakery. Welcome to Hollywood and the wonderful world of bloatware.
You'll probably want to use a frame rate of at least 24/second (30fps preferable for smooth motion) or it's gonna be an annoyingly jerky slideshow (unless you WANT or NEED it to be a slideshow). This is controlled using the tick value of the Live Wallpaper service. Want 30fps for a smooth animation? 1000/30 = 33, so that means a new image gets cycled with a tick value of 33. A frame rate of 24 fps means cycling a new image with a tick set to 42. And whatever animation software you use to create the series of images will need to be set at the same frame rate that you use in your LWP. Remember that.
Also know that cycling images puts a load on the processor the same way playing a movie does. Same exact thing, zero difference. As such, you will notice that this puts a bit of a performance lag on the phone when you're sliding home screens left and right. This does NOT happen when any app is launched, however, as the LWP then hibernates. This lag is not severe, but noticeable compared to non-movie, efficient, complex LWPs. No particular reason I mention this other than an FYI factoid for the sake of it.
LWP developers who write the really super high-class, complex, real Java-animated LWPs (the ones that use true 3D graphics, loads of animation code, perform beautifully smooth, and put virtually no load on the phone) criticize these types of LWPs mostly for marketing purposes, but they are correct - the type of LWP I describe above is in fact a "looping movie" that puts a recognizable (but not severe) load on the processor and battery.
If you plan on cycling images to animate your LWPs like so many of us do, fair warning: the more resolution, color and movement in your images, the bigger the files are and the more "processing bandwidth" they use. Keep your loops short enough to keep the APK file size down - live wallpapers are generally considered hideous bloatware if they exceed 9 megabytes. You can go over 10mb with just a few seconds of animated image looping! No matter what, your finished LWP should be under 10mb, and under 5mb if you're wise and took the time to find your "magic combination. All the best ones out there are very small (usually 2-5mb). You'll have to find the magic combination of frame rate, image quality, and resolution on your own to see how it works for your app. And each app can be different. When my LWPs end up being about 2-3mb, I kick the image quality or resolution up to get it up to about 5mb just for quality's sake, but only when it makes sense to do so. Good judgment is called for with these things.
As for a previous comment about the "instability" of using list arrays for animating LWPs, I strongly disagree. Every single one of my LWPs are solid as a rock using that method, and a few of my LWPs include multiple list arrays nearly 2,000 images in size (the size of the list arrays themselves, not actual image count). Read that again. If your LWP is unstable, you've done something wrong.
No, list array-driven LWPs are not perfect performance-wise, but close enough to not have anybody in my world complaining one bit - I have not heard of any instabilities or crashes from any of my customers. The only thing any of my LWPs might suffer from is if I make the mistake of choosing boring subject material or create crappy-looking graphics content.
Sorry for the epic novel, but somebody out there is gonna be happy about this. And that definitely would have included me last year.
Last edited:
