MoveMeter not showing my meter

[jsmorley]

For instance this makes sense if there is a LeftMouseUpAction option set, which increments a variable and the value of that variable might change into another process as well. Such in a case, updating the meter without redrawing the skin might be important, to make it to immediately use the new value of the variable.
Otherwise there is indeed no reason of extra update of the meter.

Right. My point was that using UpdateDivider=-1 on meters won't have any significant effect on resources, since the bulk of the "work" done with meters is done by the redraw portion of the Update cycle of the overall skin.

[balala]

Right. My point was that using UpdateDivider=-1 on meters won't have any significant effect on resources, since the bulk of the "work" done with meters is done by the redraw portion of the Update cycle of the overall skin.

Alright, but what I posted was a situation when updating a meter has an real effect even if a redraw isn't done. Replying to your following post:

I can't imagine any skin where doing extra updates of meters, without any extra redraws of the skin, would have any real impact at all.

[jsmorley]

Alright, but what I posted was a situation when updating a meter has an real effect even if a redraw isn't done. Replying to your following post:

Sorry, what I meant was no impact on resources... That was sorta what we were talking about.

[jsmorley]

My point was and is that is seems logical that if you have a meter, and what it displays is dependent on a measure that is only updated when a mouse action is executed, it would be most efficient to have both the measure in question and the meter in question have UpdateDivider=-1 on them, and then have the mouse action do !UpdateMeasure / !UpdateMeter / !Redraw to drive things. This is technically true, but the benefit of the UpdateDivider=-1 on the "meter" is just not going save any significant resources, while the UpdateDivider=-1 on the "measure" likely will. Yes, if the skin has Update=1000 on it, then there will be extra "updates" of the meter that aren't really needed, since they will be updating without anything changing, but again, the amount of work that Rainmeter does to simply update a meter pretty much rounds to zero.

Putting UpdateDivider=-1 on the meter(s) in this case certainly won't hurt, and strictly speaking is a hair more efficient, but I guess I'm saying it's not something that you need to worry about doing.

One instance of where UpdateDivider=-1 might be of use on a meter is if you have an OnUpdateAction option on the meter. Not having that fire unnecessarily may be of value.

This topic may be of some interest...

https://forum.rainmeter.net/viewtopic.php?f=118&t=34774#p172504

[balala]

My point was and is that is seems logical that if you have a meter, and what it displays is dependent on a measure that is only updated when a mouse action is executed, it would be most efficient to have both the measure in question and the meter in question have UpdateDivider=-1 on them, and then have the mouse action do !UpdateMeasure / !UpdateMeter / !Redraw to drive things. This is technically true, but the benefit of the UpdateDivider=-1 on the "meter" is just not going save any significant resources, while the UpdateDivider=-1 on the "measure" likely will. Yes, if the skin has Update=1000 on it, then there will be extra "updates" of the meter that aren't really needed, since they will be updating without anything changing, but again, the amount of work that Rainmeter does to simply update a meter pretty much rounds to zero.

Putting UpdateDivider=-1 on the meter(s) in this case certainly won't hurt, and strictly speaking is a hair more efficient, but I guess I'm saying it's not something that you need to worry about doing.

Yes, not too important, but a workaround of this is to let the measure updating "normally" and set the UpdateDivider=-1 on the appropriate meter. Then an OnChangeAction option of the measure should update the meter (and eventually redraw the skin) when the associated measure is changing.
However as you said, probably doesn't worth to complicate things this way, especially if this doesn't have an impact on performances.

[jsmorley]

Anyway, my only point is that updating a measure is like looking up some fact on the internet. You have to open your browser, type in what you are searching for, wait for it to load, and read the fact. Updating a meter is like remembering a fact. The information has to travel at the speed that neurons operate at, presumably pretty fast, a few micro-somethings from long-term-memory to the active part of your brain.

Your mileage may vary depending on how many drugs you did in college...

[balala]

Anyway, my only point is that updating a measure is like looking up some fact on the internet. You have to open your browser, type in what you are searching for, wait for it to load, and read the fact. Updating a meter is like remembering a fact. The information has to travel at the speed that neurons operate at, presumably pretty fast, a few micro-somethings from long-term-memory to the active part of your brain.

Your mileage may vary depending on how many drugs you did in college...

Good comparison...

[Yincognito]

In general, updating meters is very low-cost. It's mostly just internal and the amount of time it takes just rounds to zero. Updating measures is a tad more expensive as almost all of them go out and do something using a Windows API call or some other more external process. Redraw is the most expensive, as it does a lot of the sizing of images and such, and redraws the entire skin on each update.

I can't imagine any skin where doing extra updates of meters, without any extra redraws of the skin, would have any real impact at all.

Many thanks for the answer - and sorry for the delay in mine. I was trying to gain some space by "aligning" the elements of my tooltip skin (icon, title, text) in a different way:
ICON - TITLE     instead of     ICON - TITLE
T   E    X    T                                    TEXT
using the vertically "self centered" - based on own height - title, while also doing some wrapping on the title based on the difference between the text and the icon. That meant all the meters were interdependent on each other, and successive updates were required for them to get to the proper position and dimensions - hence the question. In the end though, although successful in this attempt, I decided to drop it in favor of the "classic" alignment, after seeing that apart from more meter updates (just 3 more, not much), I was actually losing space instead of gaining, with the classic alignment resulting in a smaller skin (in number of pixels). So I went back to the "old way", which is not only lighter, but much easier in terms of computing positions (just some 0R and 0r and no additional updates).