Update, System Time and Animations

[jsmorley]

Recently there has been some discussions about doing animations or other finely timed events in Rainmeter, and I wanted to try to clarify a bit what the limitations of Rainmeter are in this area.

First, let me state up front (as we have many times in the past) that Rainmeter is not designed for, nor very good at, really finely tuned animation effects. You can certainly animate things using several approaches, and some very spiffy things have been done by users. What is difficult is getting animations that are "smooth" where there are lots of small changes in a short period of time, or having animations that are expected to be "timed" in some exact way.

There are several factors that play a role, and should be considered when designing a skin:

The Update option in [Rainmeter] is based on a message queue function in Windows that has a resolution of about 10-16 milliseconds. What this means is that you really just can't set the Update value in a skin to less than Update=10. Any value less than 10 is just going to end up with a behavior that is approximately the same as if you set the option to 10 to start with.

This message queue function is not based on "exactly xxx milliseconds", but is a rough approximation based on the load on your system and other factors. Update=1000 doesn't really mean exactly every 1000 milliseconds, or exactly every one second. The skin might next update at 995 milliseconds, or 1005 milliseconds. For 99.9% of Rainmeter needs, that is a distinction without a difference. If you try to depend on Update to behave like "time" in a very fine way, it can disappoint.

Rainmeter does things sequentially (with some exception for WebParser and FileView) and not in parallel, so how often a skin is actually updated is somewhat dependent on what other work (in other loaded skins for instance) Rainmeter has to do during one update cycle. If you have a skin that does a lot of work, and takes 200 milliseconds to complete, all other skins will have an effective minimum update rate of 200 milliseconds. For most skins this is again not important, but if you are running a lot of skins, or have skins that do a lot of work, an animation that depends on a very low Update rate can experience some "stuttering" at times.

The Update rate in Rainmeter has nothing at all to do with the system clock or "time". Nothing. There is literally no way to sync up some animation based on Update / UpdateDivider with the system clock or a Time measure. You can certainly drive an animation of some kind by the value of a Time measure, but understand that the animation must then work as you want with an accuracy of one second per event, as that is as granular as the Time measure gets.

None of this is to say that you can't do clever animations in Rainmeter, with things sliding in and out, icons moving when you click on them, Rotator and Roundline meters running around in circles, and any number of other fun things. It does mean that some consideration should be given to the limitations of Rainmeter when designing skins.

[Krainz]

From my perspective, Rainmeter does a fine job when running one animation per time. Thus, in order to optimize efficiency, the user should configure all meters to have an updatedivider of -1, and then change it through setoption every time one would want to start an event (such as an animation).

I see little to no need of running more than one animation at once.

[Chuck]

Very helpful post, made me understand things a little bit more.
Also, for some reason:

[Brian]

Also, for some reason:

Looks like jsmorley needs a new avatar!

-Brian