!!! HyperColor Fluid Particles S4 by Android Kraków

Video:


Google Play Link:
https://play.google.com/store/apps/...wxLDIxMiwiY29tLnppYmkuaHlwZXJjb2xvci5uZXh0Il0.

Google Play Link:
https://play.google.com/store/apps/details?id=com.magicfluids

Hmm the developer names are different, although it's possible that this is the same person.
I really enjoy the fluid flow in this wallpaper. I wonder how it is implemented. I mean it responds and renders so quickly. I've dabbled in fluid flow implementation but wasn't able to produce such smooth and quick simulation. I used Jos Stam's fluid solver implementation however, maybe there are simpler thus quicker implementations at work in this wallpaper. For example this is a wallpaper that uses the Jos Stam fluid solver to render and simulate the smoke, but it runs significantly slower than Magic Fluids above.



Google Play Link:
https://play.google.com/store/apps/...am.livewallpapers.sexyweedgirllivesmoke&hl=en

Hmm I don't know of any emulators that would gauge battery usage because the emulator runs on a computer, not a phone.
Although technically speaking this should be possible. There are 2 core variables to account for:

The amount of memory your app uses (boils down to how many bitmaps are loaded into memory)
The complexity of the rendered scene (how many and what type of draw calls are made to render your scene)

If it could be determined how much charge is necessary to complete both actions, then it's a simple formula to calculate the
discharge rate given the frame rate. This is hard to do.

Another way would be to test your app by timing how long will take for the whole battery to drain completely and compare
that to a base case such as a black background live wallpaper. In both tests, making sure that phone use is the same.
This will allow you to see how much battery time is taken away from a static background phone by using your live wallpaper app. As long as you precisely control phone usage
during both tests, the results would be accurate. From here its a simple calculation to determine the discharge rate which is the quantity you would then compare with other apps.

One thing that needs to be accounted for when comparing discharge rates are relative screen sizes of devices. A bigger screen will require more charge to draw onto. The closer the two screen sizes are to each other,
the more representative the particular discharge rate would be. For example, given the same wallpaper and identical device use, the discharge rate for a Galaxy Nexus would be lower than on a Nexus 10 because
the screen are of the Nexus 10 is almost 5 timer larger.

Anyway, it's a sizable effort either way, but perhaps someone on here will be willing to conduct a rigorous empirical study. Perhaps someone already has, I haven't googled enough.

Of course a bigger battery will last longer, but capacity has nothing to do with discharge rate which is what you would be comparing. You're right about the battery types, some devices might have more efficient batteries than others, but I think this difference is negligible.

A small note on memory use:

Small .apks should not be uses as a gauge for efficient battery use. Size has nothing to do with it. Batterly life is almost entirely dependent on 2 things, the complexity of the scene and the frame rate (how many things are you drawing and how often). It is possible to write an app that's a few kilobytes in size but drains the battery very quickly. The same applies for large apk sizes. Apps with huge apks might not drain the batterty at all.

Also, apk size is different from memory consumption when the app is in use. This promarily aplies to images. To see what I mean, on your device, go to your settings>apps and pick a wallpaper app that's running, check how many megabytes of memory it is using and compare that to the apk size. The difference is huge. This is because images take up a lot more space when loaded into memory, much more than on a hard-drive.

Image memory consumption is directly proportional to resolution. The image bellow is 1440 x 1280 pixels - a standard Galaxy S3 wallpaper. Its size is only 147kb, but when this image is
converted into a Bitmap object and placed in memory, this is how Android parses images before drawing, it takes up 7mb!!! That's almost 50 times greater.

My point is that images tend to raise memory consumption significantly enough to start affecting battery life more considerably. Be careful when loading images into memory.

To see how many megabytes an image will need when loaded into memory, multiply the resolution and divide by 2^18. For example, for our image bellow (1440 x 1280), the calculation is as follows:

= 1440 * 1280 / 2^18
= 1843200 / 262144

= 7.03125 mb

~ 7mb

Animated Gifs are not loaded the same way into memory as other images. Although I do not know the details, I suspect that animated gifs, like videos, are optimized in the way their memory is managed otherwise they would consume a lot of space. You can read more about the way Android manages animated gifs (including videos) and images. For example Gifs use a Movie Object while other images use a Bitmap Object to manage resources.

As far as scaling and sizing of images and animated gifs goes - do not worry. LWC 3 will automatically scale and sample your resources (images and gifs) depending on the given screen size at run time. All memory is managed automatically as efficiently as possible. Users of LWC do not have to do any work in that regard. This is a powerful feature, on top of managing memory, it allows complete customization of location, size and alignment of images/gifs on the canvas by the designer using a simple interface. It is actually easier to use than LWC2 and creates a smaller apk size by eliminating redundancy in resources. One image fits all screen sizes.

In later updates we are planning on adding support for dynamic objects such as basic shapes, gradients and some SVGs, which take up almost no memory. Users will be able to increase the complexity of their scenes without sacrificing precious memory.

SVGs!