Rainmeter Real Time System (RTC)

[Basya Lanti]

Hi,

For some time now I have been working on a skin containing multiple animations and Selector Menus for a project that I'm preparing for future use.
So far, the unfinished skin is working normal, howhever the side effect is the enormous system resources that RainMeter consumes when activating this skin.
RainMeter.ini has been cleaned, leaving only the active skin alone, but still no noticable results.

All my other attemps to address the overal skin problem head on, failed so far.
While thinking of a solution, then it hits me that the animation and update problem should be addressed and solved from the source (kernel) of RainMeter itself.

Therefore, Respectfully I would like to make the following suggestion to the RainMeter Developers:

1. implement a native built-in "millisecond" RTC timer code with built-in addressable flags, that then can be invoked by any skin configuration and skin Meter independantely.

The result is that only the skin sections that require a rate of 20 ms (50 Hz) or 16.67 ms (60 Hz) for smooth and flawless animations and scrolling, will use this feature.
Other skin sections that don't need to run real time, could then just be set to use the default RainMeter update rate or a lower update rate.
And the rest of the skin section that only needs update at refresh time could then be set at a "update only once" mode (RTC=0).

This will free up CPU load enormous from let's say 50% to less than 6%.

2. The built-in RTC code should run from 0 ms to 20 ms non stop and resetting each time and stamping its realtime changing state in an addressable flag that than externaly can be read by skins configs, skin sections or skin meters.

e.g. built-in syntaxes RTC:

#RTC#
;Activate RainMeter RTC witin any skin or skin section or skin meter.
;RTC=0 (update only once at refresh time) RTC=1 (0-20 ms "smooth anims") or RTC=2 (0-250 ms "smooth video framing") or RTC=3 (0-1000 ms).

#RTCProbe#
;Setting your desired RTC ms (0-1000 ms) on which you want the skin, section or Meter to run (e.g. RTCProbe=20).

#RTCState#
;Telling RainMeter you wish to probe its internal RTC flag bit.

#RTCStamp#
;Real time RainMeter RTC stamp flag bit.

#IfRTCValue#
;Setting your desired RTC value.

#IfRTCAction#
;Reading and coping the current built-in RTC time stamp, or simply perform a bang based on the RTC given value.

#RTCWAIT#
;Telling RainMeter to temporarely ignore given skin, skin section or skin meter for 1 or more RTC cycles (value = 1 to 1000).

#RTCSKIP#
;Telling Rainmeter not to update or run RTC on a certain skin, skin section or skin Meter.
;"RTCSkip" will let rainmeter totally ignore a skin, a skin section or skin meter.

e.g. meter code, using suggested feature with built-in RTC flag:

[VARIABLES]
RTCFLAG=0
;Your own secondary RTC flag within your skin config.

[ANIMATION_STYLE]
;Telling RainMeter to invoke build-in RTC.
Meter=RTC
;Initialize.
Measure=RTCState
;RainMeter RTC set at 0-20 ms.
RTC=1
;Update this Meter every 20 ms.
RTCProbe=20
;Checking RainMeter RTC state for every 20 ms.
IfRTCValue=20

;Set new RTC timing to your dynamic variable flag bit.
;Any section can than use flag info to update themselfs independantely.
;Or just wait 1 or more RTC cycles using "RTCWait".

IfRTCAction=[!SetVariable RTCFlag "#RTCSTAMP#"]
DynamicVariable=1

[ANIM_EXAMPLE1]
Meter=Bitmap
MeterStyle=ANIMATION_STYLE
;Checking RainMeter RTC state for every 10 ms.
IfRTCValue=10
;Perform desired !Bang action.
IfRTCAction=[!ShowMeter ....][!ToggleMeter ....]
;Code your Image or Bitmap anim stuff...
...
...

e.g. animation without meter styles:

[ANIM_EXAMPLE2]
;When RainMeter encounter "RTC=1", it will use RTC (0-20 ms) on this Meter.
RTC=1
;RTC update rate of this Meter is 10 ms.
RTCProbe=10
Meter=Bitmap
;Code your Image or Bitmap anim stuff...
...
...

Please notice also that it should be made possible to use semicolons at the end of the lines, followed by comments.
That's another feature I also would like to suggest to the RainMeter Developers to implement.
It will make skins more readable and explanable troughout the whole skin.

Considering RTC suggestion, a skin or skin section or skin Meter can than deside independantely on which update rate to process.
Skin meter rate settings must then also have the abillity to overrule the rate settings in the skin config or higher configs.
This will make the proper use of smooth animation and video framing possible and that would make RainMeter grow up more and shine like never before.

This feature will naturely in a positive way be noticed by many users and future Developers.

In general speaking, what I'm greatly missing in RainMeter is the feature to have skins and skin meters to independantly update from each other without holding back one another at updating time, because it's really noticable in animation codes.

I don't know if above question / suggestion already have been asked before, but I sure will appreciate a workable feedback on this one.

Thanks in advanced,

Basya Lanti (an old Amiga ASM coder from the golden days)

[Mordasius]

Have you tried using UpdateDivider to set independent update rates on measures and meters?

[Basya Lanti]

Have you tried using UpdateDivider to set independent update rates on measures and meters?

Yes I have tried that but the result was not to my satisfaction.
Besides, the goal is to reduced the havy system load and with UpdateDivider I doesn't seem to be achievable.

[jsmorley]

I agree that the idea of setting Update very low (to support animations) and using UpdateDivider on EVERY measure and meter other than the ones needing the low update rate should work, but doesn't fully. The impact on CPU usage is still undesirable.

We appreciate the detailed suggestion. Not sure how we are going to solve this going forward, as in some ways any change to how Update / UpdateDivider works in Rainmeter is both a radical change to the DNA of the app, and has a lot of backwards compatibility issues that we need to always consider.

We have been actively looking at this issue for some time, and have some ideas on a way to move the bar (pun intended) in the right direction. Nothing is going to happen in 2.4 of Rainmeter, but stay tuned for possible improvements in how animations are done in 2.5.

[Mordasius]

Setting UpdateDivider to a multiple of the overall Update value seems to work fairly well for me in most cases but I guess we'd better leave this for a few words of wisdom from one of the Developers.

(and the words were spoken before I'd even hit Submit )

[poiru]

Setting UpdateDivider to a multiple of the overall Update value seems to work fairly well for me in most cases but I guess we'd better leave this for a few words of wisdom from one of the Developers.

The skin is redrawn on every Update even if a single meter has UpdateDivider=1. Drawing is one of the most expensive operations, so it can incur high resource consumption depending on the complexity and size of the skin.

In the ideal case, the skin would be redrawn only when something actually changes (e.g. when the value of a measure bound to a meter changes).

[Mordasius]

The skin is redrawn on every Update even if a single meter has UpdateDivider=1.

Do you mean even when UpdateDivider=-1 ?

If so, have I been wasting my time trying to save resources by putting UpdateDivider=-1 on all those 600x400 pixel background images?

[poiru]

Do you mean even when UpdateDivider=-1 ?

Nope, I mean UpdateDivider=1. Even if a single meter is has UpdateDivider=1 (i.e. it updates on every single update cycle), the entire skin is redrawn on every update cycle.

If so, have I been wasting my time trying to save resources by putting UpdateDivider=-1 on all those 600x400 pixel background images?

No. With UpdateDivider=-1, the meter will not update (which is different from redrawing) and thus you will save at least some resources. In the future, using UpdateDivider=-1 may yield even greater savings so you should definitely continue to do so.

[XANCI]

So far in my suite all skins' positions are fixed so I have a single .ini file with Update=20 to perform all animations, leave other skins the default update rate to display information.