Question on DynamicVariables=1

[Yincognito]

Thanks, Brian - all clear now.

[jsmorley]

In "production" skins, what I like to do is instead of using a "dummy" option to force a one-time dynamic reading of options, is to use the DynamicVariables option itself.
[!SetOption SomeSection DynamicVariables "0"]

This way you can still understand "why" you placed that there at a later time when the skin isn't so fresh in your mind. Or if you happen to distribute the skin, other users can attempt to understand what you are doing. [!SetOption Something Dummy ""] isn't going to make a lot of sense to most users, and might even throw you for a loop 2 years later when updating your skin.

-Brian

That's a good idea.

[mmxiv]

Hi! I need some clarification please.
Option DynamicVariables=1 is completely off when a measure has set Disabled=1. Hope that's right. But what's going on with DVs, or better resource usage when meters with Hidden=1 have it set? The metters are Hidden, but are they completely inactive in that case?
We indeed see nothing of such meters when hidden, but I think there is still someting invisible active that uses little bit of the hardware resources.
Please correct me and clarify the thing if I'm mistaken.

[jsmorley]

Hi! I need some clarification please.
Option DynamicVariables=1 is completely off when a measure has set Disabled=1. Hope that's right. But what's going on with DVs, or better resource usage when meters with Hidden=1 have it set? The metters are Hidden, but are they completely inactive in that case?
We indeed see nothing of such meters when hidden, but I think there is still someting invisible active that uses little bit of the hardware resources.
Please correct me and clarify the thing if I'm mistaken.

DynamicVariables will not impact performance when a measure is disabled. The processing of the measure is entirely skipped.

However, when a meter is hidden, all resolution of all options on the meter is done, and DynamicVariables will still cause any resolution of those options to take place dynamically on every update of the meter. The hidden value of a meter simply sets the width and height of the meter to zero, effectively hiding it, but the meter still exists and is still fully "alive".

In order to stop any dynamic resolution of options on a meter, you should use UpdateDivider=-1 on the meter, which will only update it one time when the skin is first loaded or refreshed. You can then force a single update of the meter on demand, by using !UpdateMeter or !UpdateMeterGroup in an action.

You can also use !SetOption to "toggle" the value of UpdateDivider between 1 and -1 to turn the meter on and off, followed by !UpdateMeter to cause Rainmeter to react to that change. It has to update the meter in order to see that the value of UpdateDivider has been changed...

Code: Select all

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1

[Variables]

[MeasureCounter]
Measure=Calc
Formula=Counter

[MeterExample]
Meter=String
FontSize=11
FontWeight=400
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
AntiAlias=1
UpdateDivider=-1
DynamicVariables=1
Text=[MeasureCounter:]

[MeterUpdateOnce]
Meter=Image
Y=5R
W=20
H=20
SolidColor=137,194,255,255
LeftMouseUpAction=[!UpdateMeter MeterExample][!Redraw]

[MeterTurnOn]
Meter=Image
X=5R
Y=0r
W=20
H=20
SolidColor=66,255,66,255
LeftMouseUpAction=[!SetOption MeterExample UpdateDivider "1"][!UpdateMeter MeterExample]

[MeterTurnOff]
Meter=Image
X=5R
Y=0r
W=20
H=20
SolidColor=255,101,97,255
LeftMouseUpAction=[!SetOption MeterExample UpdateDivider "-1"][!UpdateMeter MeterExample]

The !UpdateMeter in MeterTurnOn is required, or it will never see the change. The !UpdateMeter in MeterTurnOff is optional, but will keep the meter from being updated one more time after the change.

We don't have an explicit "disabled" value on meters, since in our view it's really not needed. The "update" of a meter uses so little resources that it really rounds to zero, no matter what options you use or what state DyanmicVariables is in. 99% of the work done by a meter is in the "redraw" of the overall skin, not the "update" of a given meter. Still, "rounds to zero" is not the same as "is zero", so by all means I'm fully in favor of fine tuning as much as you like.

[mmxiv]

jsmorley

I got decreased CPU usage for of 3-4% after I have set UpdateDivider=-1 to all da hidden meters with DynamicVariables. There is more than 100 such meters. So it makes difference as I thought and in big gadgets hiddden meters without that option eat more resources for nothing.
But do the hidden meter with UpdateDivider=-1 update when we refresh, load and unload the configuration or refresh the entire Rainy either manually or altogether with other actions related to the entire Rainmeter?

[jsmorley]

jsmorley

I got decreased CPU usage for of 3-4% after I have set UpdateDivider=-1 to all da hidden meters with DynamicVariables. There is more than 100 such meters. So it makes difference as I thought and in big gadgets hiddden meters without that option eat more resources for nothing.
But do the hidden meter with UpdateDivider=-1 update when we refresh, load and unload the configuration or refresh the entire Rainy either manually or altogether with other actions related to the entire Rainmeter?

Yes, any refresh of the skin will again update the meters one time when UpdateDivider=-1

[Yincognito]

I got decreased CPU usage for of 3-4% after I have set UpdateDivider=-1 to all da hidden meters with DynamicVariables. There is more than 100 such meters. So it makes difference as I thought and in big gadgets hiddden meters without that option eat more resources for nothing.

True. In a nutshell, these are the main factors that increase the CPU usage in the case of meters:
- updating (through redrawing, as jsmorley mentioned; faster update rates means more frequent redrawing, thus more CPU usage)
- size (bigger meters take more CPU, and it doesn't matter if the meter is hidden or even outside the skin area)
- number (obviously, the more meters you have, the higher the CPU usage)
- dynamic variables, nested variables, complex mathematical formulas in its options (as pointed out, these are minimal compared to the two above)
All these have a cumulative effect, meaning that the CPU usage increases a lot faster if more of the above are true.

P.S. I'm not sure if the type of the meter has any effect on the CPU usage (e.g. having the meter as Shape vs Image or viceversa, etc.), but if it has an impact, that is probably minimal as well.

But do the hidden meter with UpdateDivider=-1 update when we refresh, load and unload the configuration or refresh the entire Rainy either manually or altogether with other actions related to the entire Rainmeter?

Yes. They update once at skin refresh/load, that's it. Any action performing a skin refresh/load is going to update the UpdateDivider=-1 meters as well.

[mmxiv]

Thanks guys. One more asking:
Does the UpdateDivider support formulas in it?
In other words, is there a way to control them over variables?
Example:
UpdateDivider=(#VarUpd#=1) ? 1 : -1

[Yincognito]

Thanks guys. One more asking:
Does the UpdateDivider support formulas in it?
In other words, is there a way to control them over variables?
Example:
UpdateDivider=(#VarUpd#=1) ? 1 : -1

Yes. If your #VarUpd# is dynamic (i.e. it changes while the skin is active), make sure you also have a DynamicVariables=1 in the respective meter.

[balala]

Yes. If your #VarUpd# is dynamic (i.e. it changes while the skin is active), make sure you also have a DynamicVariables=1 in the respective meter.

And one more: if the VarUpd is set with !SetVariable bang (what I suppose)into an option (a LeftMouseUpAction for instance), in the same option there is needed a !UpdateMeter or !UpdateMeasure bang as well, which updates the meter or measure where the above UpdateDivider option (which uses the formula) is used, because otherwise when the VarUpd variable is set to any other value than 1 (so the UpdateDivider option of the meter / measure is set to -1), you never get the meter / measure updated, so when later the VarUpd variable is set back to 1, the meter or measure isn't updated anymore, so you won't see a change.

Thanks guys. One more asking:
Does the UpdateDivider support formulas in it?
In other words, is there a way to control them over variables?
Example:
UpdateDivider=(#VarUpd#=1) ? 1 : -1

Recommend to include the whole formula used into the UpdateDivider option into parentheses: UpdateDivider=((#VarUpd#=1) ?1:-1) (as you see here I also would get rid of the unecessary spaces).