Whats the most efficient method for transitioning between two images (Like Mac wallpaper change)

Question

I'm working on a wallpaper application. Wallpapers are changed every few minutes as specified by the user.

The feature I want is to fade in a new image while fading out the old image. Anyone who has a mac may see the behavior I want if they change their wallpaper every X minutes.

My current thoughts on how I would approach this is to take both images and lay one over the other and vary the opacity. Start the old image at 90% and the new image at 10%. I would then decrease the old image by 10% until it is 0%, while increasing the new image by 10% until 90%. I would then set the wallpaper to the new image.

To make it look like a smooth transition I would create the transition wallpapers before starting the process instead of doing it in real-time.

My question is, is there a more effective way to do this?

I can think of some optimizations such as saving the transition images with a lower quality.

Any ideas on approaches that would make this more efficient than I described?

Answer 1

Pre-rendering each blended frame of the transition will take up a lot of disk space (and potentially bandwidth). It would be better to simply load the two images and use the graphics card to do the blending in real time. If you have to use something like openGL directly, you will probably be able to just create two rectangles, set the images as the textures, and vary the alpha values. Most systems have simpler 2d apis that would let you do this very easily. (eg. CoreAnimation on OS X, which will automatically vary the transparency over time and make full use of hardware acceleration.)

Answer 2

Sounds like an issue of trade-off.

It depends on the emphasis:

• Speed of rendering
• Use of resources

Speed of rendering is going to be an issue of how long the process of the blending images is going to take to render to a screen-drawable image. If the blending process takes too long (as transparency effects may take a long time compared to regular opaque drawing operations) then pre-rendering the transition may be a good approach.

Of course, pre-rendering means that there will be multiple images either in memory or disk storage which will have to be held onto. This will mean that more resources will be required for temporary storage of the transition effect. If resources are scarce, then doing the transition on-the-fly may be more desirable. Additionally, if the images are on the disk, there is going to be a performance hit due to the slower I/O speed of data outside of the main memory.

On the issue of "saving the transition images with a lower quality" -- what do you mean by "lower quality"? Do you mean compressing the image? Or, do you mean having smaller image? I can see some pros and cons for each method.

• Compress the image

  • Pros: Per image, the amount of memory consumed will be lower. This would require less disk space, or space on the memory.
  • Cons: Decompression of the image is going to take processing. The decompressed image is going to take additional space in the memory before being drawn to the screen. If lossy compression like JPEG is used, compression artifacts may be visible.

• Use a smaller image

  • Pros: Again, per image, the amount of memory used will be lower.
  • Cons: The process of stretching the image to the screen size will take some processing power. Again, additional memory will be needed to produce the stretched image.

Finally, there's one point to consider -- Is rendering the transition in real-time really not going to be fast enough?

It may actually turn out that rendering doesn't take too long, and this may all turn out to be premature optimization.

It might be worth a shot to make a prototype without any optimizations, and see if it would really be necessary to pre-render the transition. Profile each step of the process to see what is taking time.

If the performance of on-the-fly rendering is unsatisfactory, weigh the positives and negatives of each approach of pre-rendering, and pick the one that seems to work best.

Answer 3

On the fly rendering should be quick enough if handled by the graphics card, especially if it's the same texture with a different opacity (a lot of graphics rendering time is often loading textures to the card, ever wondered what game loading screens were actually doing?)