It is currently May 20th, 2019, 11:44 pm

DefaultUpdateDivider

Changes made during the Rainmeter 3.2 beta cycle.
User avatar
jsmorley
Developer
Posts: 19245
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

DefaultUpdateDivider

jsmorley » September 16th, 2014, 7:37 pm

We have added a new DefaultUpdateDivider option to the [Rainmeter] section of skins.

This is intended to allow you to set a low Update rate on a skin, to support animations or other skin elements that need a fast update rate, while not having to manually set an UpdateDivider on a great many other measures and meters that may not require the rapid update.

http://docs.rainmeter.net/manual-beta/skins/rainmeter-section#DefaultUpdateDivider

Example:

Code: Select all

[Rainmeter]
Update=100
DynamicWindowSize=1
AccurateText=1
DefaultUpdateDivider=10

[MeasureSlow]
Measure=Calc
Formula=(MeasureSlow % 100) + 1

[MeasureFast]
Measure=Calc
Formula=(MeasureFast % 100) + 1
UpdateDivider=1

[MeterSlow]
Meter=String
MeasureName=MeasureSlow
MeasureName2=MeasureFast
FontSize=11
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
AntiAlias=1
Text=%1 : %2

[MeterFast]
Meter=String
MeasureName=MeasureSlow
MeasureName2=MeasureFast
Y=3R
FontSize=11
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
AntiAlias=1
Text=%1 : %2
UpdateDivider=1
The way this works is that if DefaultUpdateDivider is set, (the default is "1") then all skin measures and meters will default to that as their UpdateDivider option. This can be overridden on individual measures and meters by setting their specific UpdateDivider options.

So you may have a skin with 3 measures and meters involved in some animation, and need to set the Update rate of the skin to say "20" to support this. Meanwhile, you may have 100 other measures and meters in the skin that are not involved in the animation. Previously, for the sake of resource efficiency, you would want to set all of them to UpdateDivider=50, so they only update once a second (the normal Update=1000). With this new option, you would set Update=20 and DefaultUpdateDivider=50 in [Rainmeter]. Then you would only need to set UpdateDivider=1 on the 3 measures and meters for the animation. The 100 other measures and meters are already set properly by default.

On the other hand, if you have a skin with 100 measures and meters involved in the animation, and 3 there are not, then don't set DefaultUpdateDivider, and just set UpdateDivider=50 on the 3 measures. The question you want to ask is "what saves me the most copy and pasting?"


While DefaultUpdateDivider is in the [Rainmeter] section and thus cannot be dynamically changed, individual UpdateDivider options on measures and meters of course can.

One small caution I would offer is that measures that use UpdateRate to internally track how often they perform some action will almost always be set with an UpdateRate (default 300) and no UpdateDivider. This is particularly true of WebParser parent measures, and also Ping. It is really best, from a timing standpoint, to use UpdateDivider=1 with WebParser, and set UpdateRate to control them.
User avatar
Dank420
Posts: 147
Joined: April 3rd, 2013, 1:04 am
Location: O-High-O

Re: DefaultUpdateDivider

Dank420 » September 17th, 2014, 3:43 pm

"There's no emoticon for what I'm feeling right now"

Thankyou
User avatar
killall-q
Posts: 285
Joined: August 14th, 2009, 8:04 am

Re: DefaultUpdateDivider

killall-q » September 17th, 2014, 6:12 pm

jsmorley wrote:One small caution I would offer is that measures that use UpdateRate to internally track how often they perform some action will almost always work best with an UpdateDivider of "1".
How is it "best", which implies that leaving out UpdateDivider still works, only "not as well"? Does DefaultUpdateDivider confuse WebParser? Can the formula
Update X UpdateDivider X UpdateRate = "how often the measure connects to the site"
be taken at face value?
User avatar
jsmorley
Developer
Posts: 19245
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: DefaultUpdateDivider

jsmorley » September 17th, 2014, 7:44 pm

killall-q wrote: How is it "best", which implies that leaving out UpdateDivider still works, only "not as well"? Does DefaultUpdateDivider confuse WebParser? Can the formula be taken at face value?
Yes, it can. In a sense though, UpdateDivider and UpdateRate are sorta redundant on a WebParser measure. I guess that is my bigger point. Certainly nothing about UpdateDivider "confuses" WebParser.

UpdateRate is an internal counter in the plugin. It keeps track of each time the measure is updated, and when UpdateRate is reached, the website or resource is accessed. So if you are going to use both UpdateDivider and UpdateRate, you need to consider that that UpdateRate you set to 300 isn't every 5 minutes anymore as it is if Update=1000, UpdateDivider=1 and UpdateRate=300, but is now whatever the mathematical formula of Update X UpdateDivider X UpdateRate works out to.

Generally at best it seems a pointless complication, and at worst, when it is done inadvertently, it can cause unwanted behavior. All I'm saying is that if you do use DefaultUpdateDivider, that you take into consideration what effect that might have on WebParser measures, which almost always don't have any UpdateDivider on them, but have UpdateRate instead.
User avatar
killall-q
Posts: 285
Joined: August 14th, 2009, 8:04 am

Re: DefaultUpdateDivider

killall-q » September 17th, 2014, 8:20 pm

Alright, so it's only a precaution of the possibility of confusion for authors, but there's no problem with using just Update × DefaultUpdateDivider × UpdateRate as long as you double check your math.
Wallboy
Posts: 62
Joined: October 1st, 2012, 4:53 am

Re: DefaultUpdateDivider

Wallboy » September 17th, 2014, 11:20 pm

That formula will be pretty accurate so long you don't use a low Update of around ~30 or below. See http://rainmeter.net/forum/viewtopic.php?p=103601#p103601
User avatar
jsmorley
Developer
Posts: 19245
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: DefaultUpdateDivider

jsmorley » September 18th, 2014, 11:52 am

Just to be clear, or at least more complete, on this issue with WebParser measures:

WebParser was originally designed in such a way that the intent is to drive it with UpdateRate, while leaving UpdateDivider=1.

In early versions of Rainmeter, there was a timing issue where using say UpdateDivider=300 and UpdateRate=1 would cause unwanted behavior. It still can in some cases.

On each update of the measure, WebParser is told to increment an internal counter in the plugin. When that counter reaches UpdateRate, the resource is downloaded and parsed, and the counter is reset.

The measure will "see" the new values (for both the parent and any children) as soon as the plugin is "finished" getting the data, maybe on the next update, maybe in a couple of updates. Depends on the resource being accessed. The design is such that with an UpdateDivider of "1", that means things are returned and used pretty much as soon as WebParser is done.

Remember, WebParser is "threaded" and not "blocking", so in a sense Rainmeter isn't "waiting" for an answer, but "checking" for an answer on each update of the measure.

Previously, this could cause a behavior where with UpdateDivider=300 and UpdateRate=1, there could be a "lag" of up to 299 skin updates (299 X Update) before the values returned by the plugin would be seen and used by the skin. With UpdateDivider=1 and UpdateRate=300, that "lag" could only be from zero to Update milliseconds, generally less than a second.

This issue was partially corrected a long while back as a part of a bigger change to some timing methods with update, where some things that were done at the "beginning" of the update cycle were moved to the "end" of the update cycle.

However, due to the nature of the way Rainmeter is structured, the change only impacted the timing of "string" values returned by WebParser. If any StringIndex returns a string that represents a "number". Rainmeter will create a true number value for the measure, and due to the timing of when that conversion to a number happens, that value can still have the "lag" if you use UpdateDivider instead of UpdateRate to control things.

So this can still cause an issue if you use a number value returned by a WebParser parent or child measure in a Calc measure, IfAction, IfCondition, [SectionVariable:] or any other numeric formula.

The long and the short of it is that you should almost never use UpdateDivider with WebParser parent OR child measures. Leave it as the default "1", and use UpdateRate on the parent to control the timing of when things are done. If you have a low Update, set UpdateRate higher... While in many cases there won't be a difference, the risk of unwanted behavior, while "small", isn't outweighed by any advantages, which really are "none".

UpdateDivider can be used with it if you have a skin with a very low overall Update rate, to make things as efficient as possible by carefully setting both UpdateDivider and UpdateRate to sorta get the behavior back to what it would be with a normal Update=1000, but other than that just use UpdateRate to drive things. Really, at the end of the day, Rainmeter just "checking" the measure for a value and telling the plugin to increment the UpdateRate counter is one of the least resource intensive things Rainmeter does. There is little need to jump through hoops to avoid that.
User avatar
exper1mental
Posts: 282
Joined: January 9th, 2013, 7:52 pm
Location: Southern USA

Re: DefaultUpdateDivider

exper1mental » September 18th, 2014, 3:09 pm

Day. Made. :thumbup:
Image
User avatar
killall-q
Posts: 285
Joined: August 14th, 2009, 8:04 am

Re: DefaultUpdateDivider

killall-q » September 18th, 2014, 4:48 pm

Thanks for the reply, that clears up a lot of voodoo.
User avatar
iNjUST
Posts: 118
Joined: June 20th, 2012, 12:44 am

Re: DefaultUpdateDivider

iNjUST » September 18th, 2014, 7:44 pm

Wonderful!

As an aside, do you know if we can keep hoping for a MeasureStyle? There are more options than UpdateDivider that I would love to save some coding by applying to all measures with a given style defined.