Possible performance improvements

Post your suggestions, wanted features,... for Wallpaper Cycler here.

Moderators: Marc G, Johan G

Possible performance improvements

Postby TheBlackCat » Thu Mar 01, 2007 5:59 am

I have some possible ideas that might help with performance. I don't know that much about programming for an OS, so these ideas might not work. This is all based on your post here which is obviously an extremely dumbed-down version. So these ideas might not even work with how the program runs. They are also, most likely, mutually exclusive although situations where you would need the second you probably would not be able to use the first anyway. So if the ideas are useless or impossible I apologize.

The first idea is for computers with lots of RAM. Currently, according to your description, the background is rendered in memory and then saved to a temporary files. As I am sure you know, the hard drive is the slowest part of the computer. Keeping it in RAM permanently would be a much better solution for people with lots of RAM. For dual 1600x1280 screens (really big screens) it would still be only 13 megabytes or so. If you have the RAM to spare this would take the load off the hard drive and hopefully speed things up a bit. The problem is getting windows to read the wallpaper from RAM instead of from a file. I am not sure how that would even be possible. Is there some way to trick the windows shortcut system to point to a segment in the RAM as opposed to a place on the hard drive? Keeping in in graphics card RAM might even be better, but probably even harder. This might also allow moving images to be displayed, windows directdraw or directshow or something might have the capability to render a static overlay on top of a moving image, I don't know. Windows vista can do it somehow, I am not sure how. There might be some sort of hardware acceleration for this sort of thing.

The second idea is for lower-end computers. The idea is to have the main process thread that renders the wallpaper to a temp file. However, if you have the hard drive space to spare you could also have a second, "very low" priority thread that renders two or three wallpapers ahead. That way, while the computer is not doing much (i.e. higher-priority threads are not taking up too much of the processor's time) the program can be rendering a bit ahead so the wallpaper can still cycle if the processor is too busy or the RAM too full when it comes time to render right away. It might mean a bit of a delay on RSS feeds and such, so it might render one ahead starting 5-10 minutes before the next render if there are time-dependent items on the screen and the cycle time is more than 5-10 minutes (if not then it can render as far ahead as it pleases).
Posts: 12
Joined: Sat Feb 03, 2007 5:57 pm

Postby Marc G » Thu Mar 01, 2007 10:27 am

Interesting ideas :)
However, the second idea will not work so great, because users could put a text object on the desktop with the time and this will mean that the time will not be 100% correct with the time of the cycling. Not that big of an issue I assume.

But, the first idea is interesting and will probably make it in some version of Wallpaper Cycler. However, I'm no yet sure if I will be able to put this in the next release. I will need to do some experimenting with this :)
Marc Gregoire,
[ Microsoft MVP VC++ since 2007 ]
User avatar
Marc G
NuonSoft Staff
Posts: 827
Joined: Thu Nov 07, 2002 8:19 pm
Location: Belgium

Return to WPC - Wishlist

Who is online

Users browsing this forum: No registered users and 1 guest