[Android Themes] Dirk:
Math time...

Here's some more insight into the calculations needed for some of these Animations. We'll use one of the left-to-right traversing animations in my own thread as an example. (Like one of the Enterprise ones.) We begin with an image thats 2560px wide and it's got to cross the 1080px 'window' of our screen. That doesn't mean it has to move 2560px, but 3640px, as it will be 2560px for the 'tip' of the image to emerge on the left until the 'tail' crosses the same point. The tail still has another 1080px to go before it disappears off the Right side of the 'Window'.

So if we move the image 10px to the Right per frame it will be 364 frames total. Problem is 10px at a time for images like these moving across the screen, either horizontally or vertically, is not smooth. Take a close look at the NASA (Space Shuttle) animation. It begins at 1px increments and ends at 9px increments, increasing by 1px every second. You can see the 'acceleration'. It begins smooth, but after five seconds the smoothness deteriorates and by the end is pretty janky. So for traversing images i don't like to go above 5px increments per frame.

So, 3640/5 = 728 frames. This is where we begin to think of framerate. FPS is not a factor in smoothness but of total duration. At 30fps the 728 frames will take 24 seconds. Too long. At 60fps it will take half that. (12 seconds). You can of course use anything in between. 45fps is a good compromise in this case. (16 seconds).

Sometimes with big images setting a higher fps does nothing to speed up the animation beyond a certain point. I assume in these cases it's because it's just all too much for the system to handle. It's not what people expect, but keeping the fps low is easier for the system to handle and results in less jank. The smoothness will actually improve, providing your frame-by-frame movement is no more than 5px.

Of course, one option is to resize that image before beginning to reduce the total number of frames needed to complete the animation. Take that 2560px image and make it 1080px wide and now you only have 2160px total movement. At 5px increments per frame you'll end up with 432 frames. At 30fps it's a reasonable 14 seconds. With the image 1080px wide there will be a point on it's journey across the screen where the whole image is visible at the same time, but of course it will be smaller and more distant too. I personally like the larger image. You don't ever see the whole Enterprise at once, but it's a more cinematic effect...and of course the image is bigger so therefore 'closer' and more impactful.

Smaller images do of course mean less number bashing on the keyboard. It's probably five minutes for 100 frames if you have everything set up right and are using a macro to reduce the inputs needed.

For the animations where the image zooms in and out, like the Enterprise coming and going, it's surprisingly easy for the system to handle. Much easier than the transistioning images. For these i resize the image 10px at a time and that seems perfectly smooth at any framerate. Again, the fps you choose will have more to do with the total duration of the animation than it does the smoothness.

For quality i prefer to keep images as .PNG, but the option exists to use .JPG at 90% or even 80% quality if you need something big to run better and be smaller. How much smaller? I made one yesterday that was 380MB as .PNG images. Using .JPG at 90% quality reduced it to around 90MB. (Roughly 1/4th) .JPG at 80% quality reduces it further to about 40MB, or roughly 1/9th it's original size. At 90% the difference in quality is almost unnoticeable, unless you're comparing two still frames side-by-side and looking hard.