Regular vs Animation Update - and ToolTips

[Yincognito]

I remember posting about this a couple of years back, but those years passed and things stayed the same, so I'll ask again. I have a "sliding" meter that endlessly moves from right to left in a skin, basically like a news ticker. Since this is an animation, it obviously requires setting a low Update (say, 50 milliseconds) in the Rainmeter section of the skin. While setting other non-animated meters to update less often works well by setting their UpdateDivider option, tooltips seem to update at the rate that was set in the Update option from the Rainmeter section (i.e. they use the "animation update rate"), which makes them flicker very badly, naturally. Since I use tooltips to show additional info on hover, this is certainly not desirable.

In an attempt to solve the issue, I tried to do the reverse: set a "normal" Update of 1000 milliseconds in the Rainmeter section, let the "regular" measures and meters update at that rate, and use the UpdateDivider option to lower the update rate of the measures and meter involved in the animation (the animation is controlled by a set of !SetOption, !UpdateMeter and !Redraw bangs from a "counter" measure) to the desired 50 milliseconds. Needless to say, while this obviously solved the tooltip flickering issue, it didn't succeed in building a proper animation, since the meter moves once every 1000 milliseconds instead of the 50 that the UpdateDivider supposedly should have set on the animation elements of the skin. My guess is that it didn't work because the value of the UpdateDivider can't be fractional (and it had to be that way, since the actual update rate is Update x UpdateDivider, i.e. 1000 x (50/1000) = 50 milliseconds, so UpdateDivider must be 50/1000, aka 1/20 - a fractional value).

Of course, I've also tried to set UpdateDivider=-1 on the meter that shows the tooltip on hover, not to mention using the DefaultUpdateDivider option to help with it, but that didn't solve the issue either. Any ideas what can I do to both eliminate the tooltip flickering issue and make the animation work as expected?

Relevant sections of the (simplified) skin - this is the DefaultUpdateDivider version, that sets an UpdateDivider=1 on the animation elements (as per jsmorley's advice here):

Code: Select all

[Variables]
SkinWidth=300
SkinHeight=16
UpdateInterval=1000
SlidingStep=1
SlidingUpdate=50
ScrollingStep=10
MovingStringWidth=0

[Rainmeter]
SkinWidth=#SkinWidth#
SkinHeight=#SkinHeight#
Update=#SlidingUpdate#
DefaultUpdateDivider=(#UpdateInterval#/#SlidingUpdate#)

---Measures---

[MS_Rainmeter_MovingString]
Measure=String
String=Some Moderately Long Moving String Here
UpdateDivider=-1
DynamicVariables=1

[MS_Rainmeter_Counter]
Measure=Calc
Formula=((MS_Rainmeter_Counter>=(#SkinWidth#+#MovingStringWidth#))?(0):(MS_Rainmeter_Counter+#SlidingStep#))
UpdateDivider=1
OnUpdateAction=[!SetOption MT_Rainmeter_MovingString X (#SkinWidth#-[MS_Rainmeter_Counter])][!UpdateMeter *][!Redraw]
DynamicVariables=1

---Meters---

[MT_Rainmeter_VisibleContainer]
Meter=Shape
X=0
Y=0
Shape=Rectangle 0,0,#SkinWidth#,#SkinHeight# | Fill Color 128,128,128,255 | StrokeWidth 0
ToolTipWidth=322
ToolTipTitle="Some ToolTip Title Here"
ToolTipText=""Some Long ToolTip Content Here For The Flickering To Be Easily Seen"
MouseOverAction=[!PauseMeasure "MS_Rainmeter_Counter"]
MouseLeaveAction=[!UnpauseMeasure "MS_Rainmeter_Counter"]
MouseScrollUpAction=[!SetOption MS_Rainmeter_Counter Formula ((MS_Rainmeter_Counter<=0)?(#SkinWidth#+#MovingStringWidth#):(MS_Rainmeter_Counter-#ScrollingStep#))][!UnpauseMeasure "MS_Rainmeter_Counter"][!UpdateMeasure "MS_Rainmeter_Counter"][!PauseMeasure "MS_Rainmeter_Counter"][!SetOption MS_Rainmeter_Counter Formula ((MS_Rainmeter_Counter>=(#SkinWidth#+#MovingStringWidth#))?(0):(MS_Rainmeter_Counter+#SlidingStep#))]
MouseScrollDownAction=[!SetOption MS_Rainmeter_Counter Formula ((MS_Rainmeter_Counter>=(#SkinWidth#+#MovingStringWidth#))?(0):(MS_Rainmeter_Counter+#ScrollingStep#))][!UnpauseMeasure "MS_Rainmeter_Counter"][!UpdateMeasure "MS_Rainmeter_Counter"][!PauseMeasure "MS_Rainmeter_Counter"][!SetOption MS_Rainmeter_Counter Formula ((MS_Rainmeter_Counter>=(#SkinWidth#+#MovingStringWidth#))?(0):(MS_Rainmeter_Counter+#SlidingStep#))]
DynamicVariables=1

[MT_Rainmeter_Container]
Meter=Shape
X=0
Y=0
Shape=Rectangle 0,0,#SkinWidth#,#SkinHeight# | Fill Color 0,0,0,255 | StrokeWidth 0
ToolTipWidth=322
ToolTipTitle="Some ToolTip Title Here"
ToolTipText=""Some Long ToolTip Content Here For The Flickering To Be Easily Seen"
MouseOverAction=[!PauseMeasure "MS_Rainmeter_Counter"]
MouseLeaveAction=[!UnpauseMeasure "MS_Rainmeter_Counter"]
MouseScrollUpAction=[!SetOption MS_Rainmeter_Counter Formula ((MS_Rainmeter_Counter<=0)?(#SkinWidth#+#MovingStringWidth#):(MS_Rainmeter_Counter-#ScrollingStep#))][!UnpauseMeasure "MS_Rainmeter_Counter"][!UpdateMeasure "MS_Rainmeter_Counter"][!PauseMeasure "MS_Rainmeter_Counter"][!SetOption MS_Rainmeter_Counter Formula ((MS_Rainmeter_Counter>=(#SkinWidth#+#MovingStringWidth#))?(0):(MS_Rainmeter_Counter+#SlidingStep#))]
MouseScrollDownAction=[!SetOption MS_Rainmeter_Counter Formula ((MS_Rainmeter_Counter>=(#SkinWidth#+#MovingStringWidth#))?(0):(MS_Rainmeter_Counter+#ScrollingStep#))][!UnpauseMeasure "MS_Rainmeter_Counter"][!UpdateMeasure "MS_Rainmeter_Counter"][!PauseMeasure "MS_Rainmeter_Counter"][!SetOption MS_Rainmeter_Counter Formula ((MS_Rainmeter_Counter>=(#SkinWidth#+#MovingStringWidth#))?(0):(MS_Rainmeter_Counter+#SlidingStep#))]
DynamicVariables=1

[MT_Rainmeter_MovingString]
Container=MT_Rainmeter_Container
Meter=STRING
AntiAlias=1
ClipString=0
X=0
Y=0
H=#SkinHeight#
MeasureName=MS_Rainmeter_MovingString
Text="%1"
OnUpdateAction=[!SetVariable MovingStringWidth [MT_Rainmeter_MovingString:W]]
DynamicVariables=1

[jsmorley]

No, I would try to avoid Tooltips on skins that have a low Update rate. Tooltips are based on the Update of the skin, not any UpdateDivider on a particular meter. It's done by the "redraw" of the skin.

It might be better to "roll your own" tooltip by sliding in a container with the tip, or hiding/showing some meters. There are position challenges with that of course, as you can use a plugin to get the current mouse position, but keeping the Tooltip from running off the screen is challenging.

But at the end of the day, Tooltips are controlled more by Windows than they are by Rainmeter itself, and the blinking on redraw (the more that is in the tooltip, the more noticeable it is) is just not something that can be avoided. When Windows is told to "redraw" the skin, it in effect re-creates the tooltip from scratch, thus the blinking.

Windows really didn't intend for a lot of text to be in a tooltip. It was designed for have a short "tip" like the name of an element you hover over, like "Start" and such. If a Tooltip in Rainmeter is short, you see little or no blinking. The more text is in it, the more pronounced the blinking on redraw becomes.

P.S. Nothing can ever be faster than the Update rate in the skin. You can't set that high, and use some negative or fractional UpdateDivider to make something update faster. Rainmeter doesn't work that way.

[Yincognito]

No, I would try to avoid Tooltips on skins that have a low Update rate. Tooltips are based on the Update of the skin, not any UpdateDivider on a particular meter. It's done by the "redraw" of the skin.

It might be better to "roll your own" tooltip by sliding in a container with the tip, or hiding/showing some meters. There are position challenges with that of course, as you can use a plugin to get the current mouse position, but keeping the Tooltip from running off the screen is challenging.

But at the end of the day, Tooltips are controlled more by Windows than they are by Rainmeter itself, and the blinking on update (the more that is in the tooltip, the more noticeable it is) is just not something that can be avoided.

P.S. Nothing can ever be faster than the Update rate in the skin. You can't set that high, and use some negative or fractional UpdateDivider to make something update faster. Rainmeter doesn't work that way.

No positioning challenges, actually - I've posted a topic on this some time ago and had problems with the update of the positioning, not the positioning itself, but they have been solved since. This tooltip issue was one of the reasons I attempted to make custom tooltips work, actually. I could also "move" the tooltip text in the meter itself, since because it is sliding, it will more or less be the same thing - now that's a great idea, and it suits my case, thanks!

Thing is, I'm already using tooltips in the other skins from my suite, and making this one different is kind of odd, but whatever. By the way, this is the Feeds skin we talked about, I've made the aggregator work, no "tears" involved... I would be interested in your opinion once I will post it.

Anyway, is it an impossible task to make the UpdateDivider accept fractional values? This way, I could set the "normal" 1000 milliseconds update rate in the Rainmeter section (thus avoid the flickering issue), while I could also lower the update rate of the animation measure. I know Rainmeter is all about resource efficiency and all and almost all the options take integers as input (because they take less bytes compared to float values, I assume), but a float variable instead of an integer one wouldn't be that big of a deal in the code, right?

EDIT: Just saw your edit, that's too bad you can't make UpdateDivider accept fractional values...

[jsmorley]

Anyway, is it an impossible task to make the UpdateDivider accept fractional values? This way, I could set the "normal" 1000 milliseconds update rate in the Rainmeter section (thus avoid the flickering issue), while I could also lower the update rate of the animation measure. I know Rainmeter is all about resource efficiency and all and almost all the options take integers as input (because they take less bytes compared to float values, I assume), but a float variable instead of an integer one wouldn't be that big of a deal in the code, right?

This is not going to happen. The Update / Redraw being the driver of the skin is fundamental to how Rainmeter is designed, and that isn't going to change. Without using ActionTimer, which is a separate thread, nothing can ever be faster than the Update rate.

[Yincognito]

This is not going to happen. The Update / Redraw being the driver of the skin is fundamental to how Rainmeter is designed, and that isn't going to change. Without using ActionTimer, which is a separate thread, nothing can ever be faster than the Update rate.

I see. What about "pausing" the update of the skin itself (to "freeze" the tooltip flickering while on mouse over, that is)? This isn't doable either, right? Just exploring my options...

Can the animation above be done with ActionTimer, by the way?

[jsmorley]

I see. What about "pausing" the update of the skin itself (to "freeze" the tooltip flickering while on mouse over, that is)? This isn't doable either, right? Just exploring my options...

Can the animation above be done with ActionTimer, by the way?

I think a "!SkinPause / !SkinUnpause" bang might be possible, but this would literally be the only thing it would be good for, and we are hesitant to put limited time and resources into something that really just one guy would like to have. This would have to be exclusively based on mouse actions, which are "event driven" in Windows and don't rely on the Update itself to execute. Any other use creates a conundrum, where the skin is "paused", so it will never, ever "unpause" on its own.

As to ActionTimer, I'm always hesitant to try to force that into an "endless loop". I guess it could be, having the last action on it fire the first one again, but it would need to be done carefully to avoid tearing up resources or risking overrunning the Windows message queue.

[Yincognito]

I think a "!SkinPause / !SkinUnpause" bang might be possible, but this would literally be the only thing it would be good for, and we are hesitant to put limited time and resources into something that really just one guy would like to have. This would have to be exclusively based on mouse actions, which are "event driven" in Windows and don't rely on the Update itself to execute. Any other use creates a conundrum, where the skin is "paused", so it will never, ever "unpause" on its own.

As to ActionTimer, I'm always hesitant to try to force that into an "endless loop". I guess it could be, having the last action on it fire the first one again, but it would need to be done carefully to avoid tearing up resources or risking overrunning the Windows message queue.

Got it - thanks a lot for the info! Much appreciated.