It is currently August 10th, 2020, 4:16 pm

[BUG] Specific case caused by !Redraw if in Measure in IfCondition

Report bugs with the Rainmeter application and suggest features.
User avatar
Active Colors
Moderator
Posts: 605
Joined: February 16th, 2012, 3:32 am

Re: [BUG] Specific case caused by !Redraw if in Measure in IfCondition

Post by Active Colors »

Yincognito wrote: July 25th, 2020, 8:41 am Updating the meter group should come first here, followed by showing it and redrawing the skin. At least that's how I would do it.
Yincognito, from my experience with the skin I was working, showing meter group comes first and then udating it is the second, otherwise it is not displayed properly unless it is later updated.


Secondly, my skin still chops the bottom part even after I put the measure at the very very end of the skin. The final [!Redraw] bang chops it off.
After various combinations I found out working and unworking combos:

This works (no chop):
[!ShowMeterGroup GrpCmp][!UpdateMeter *]
[!ShowMeterGroup GrpCmp][!UpdateMeter *][!Redraw][!UpdateMeter *]
[!ShowMeterGroup GrpCmp][!UpdateMeter *][!Redraw][!UpdateMeter *][!Redraw]
[!UpdateMeter *][!ShowMeterGroup GrpCmp][!Redraw][!UpdateMeter *]


This doesn't work (chop):
[!UpdateMeter *][!ShowMeterGroup GrpCmp]
[!UpdateMeter *][!ShowMeterGroup GrpCmp][!Redraw] (this doesn't properly display stuff unless updated again)
[!ShowMeterGroup GrpCmp][!UpdateMeter *][!Redraw]
[!UpdateMeter *][!ShowMeterGroup GrpCmp][!Redraw][!UpdateMeter *][!Redraw] (the last redraw causes the chop)

[!ShowMeterGroup GrpCmp][!Redraw][!UpdateMeter *][!Redraw]
[!UpdateMeter *][!Redraw][!ShowMeterGroup GrpCmp][!Redraw]
[some bangs...][!Redraw][!UpdateMeter *][!ShowMeterGroup GrpCmp][!Redraw]
[some bangs...][!Redraw][!ShowMeterGroup GrpCmp][!UpdateMeter *][!Redraw]
User avatar
jsmorley
Developer
Posts: 21235
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: [BUG] Specific case caused by !Redraw if in Measure in IfCondition

Post by jsmorley »

I would use:

[!ShowMeterGroup GrpCmp][!UpdateMeter *]

There is no good reason I can see to hammer it with redraws.
User avatar
Active Colors
Moderator
Posts: 605
Joined: February 16th, 2012, 3:32 am

Re: [BUG] Specific case caused by !Redraw if in Measure in IfCondition

Post by Active Colors »

jsmorley wrote: July 26th, 2020, 1:02 pm I would use:

[!ShowMeterGroup GrpCmp][!UpdateMeter *]

There is no good reason I can see to hammer it with redraws.
All right. For many years I perceived !Redraw as some "standard" to verify that the skin is properly showing up after all the changes made into the skin. But this time it looks other way around. Still, I can't so far deny that there is no mistake made in my skin, I need to further check it. And meanwhile I will use what you suggested. Thanks again, jsmorley!
User avatar
jsmorley
Developer
Posts: 21235
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: [BUG] Specific case caused by !Redraw if in Measure in IfCondition

Post by jsmorley »

Active Colors wrote: July 26th, 2020, 1:10 pm All right. For many years I perceived !Redraw as some "standard" to verify that the skin is properly showing up after all the changes made into the skin. But this time it looks other way around. Still, I can't so far deny that there is no mistake made in my skin, I need to further check it. And meanwhile I will use what you suggested. Thanks again, jsmorley!
The skin will always redraw at the very end of every update cycle. The purpose of the !Redraw bang is to have some visible change happen "right now", without waiting up to Update milliseconds for the next natural redraw. However, there is just no point in doing !Redraw if you don't also have some change to something visible. You will always use !Redraw in combination with one or more !UpdateMeter bangs.

That's all sorta beside the point in this case...

Again, the order of events in a skin's update cycle is:

- Update all measures in the order they are in the skin.
- Update all meters in the order they are in the skin.
- Redraw the skin window.

The purpose of your measure, presumably, is to account for the fact that a meter you are using as a "background", which must come before other "foreground" meters in the .ini file, is using the size of the meters that come after it to determine its size. In the natural order of things, that background meter will always be "one update behind", since it is asking "how big are you other guys?" before they are themselves updated.

So the new order of things, with that action in place is:

- The update cycle will update all measures, with that final measure being last. That measure will "force" an immediate update of all meters. At this point, that background meter is still "wrong", since it will still be updated first, before all the others. A redraw has not yet been done, so this doesn't matter. At the end of this all the other meters are fully updated with current measure values applied. Since the background meter is still "wrong", you do NOT want a !Redraw bang here. It's too soon.
- The update cycle will update all meters. At this point the background meter will now properly "know" the values of the meters after it, and will be "right".
- The update cycle will redraw the skin window.

Chew on that last bit. It's the reason why you are still getting the "chopped off" effect when you include a !Redraw bang in your measure. What you really want to do is to update all meters "twice", to ensure that the background meter has the current values for the meters after it in the skin, THEN let the skin redraw the window naturally.

Extra Credit:

If you really want to fine tune this, although I don't see that it is going to be of much value except perhaps in a skin with a TON of meters, you can use "groups" to target the extra meter updates a bit...

Code: Select all

[UpdateBackgroundLast]
Measure=Calc
OnUpdateAction=[!UpdateMeterGroup "ForegroundMeters"][!UpdateMeter "BackgroundMeter"]
User avatar
Yincognito
Posts: 2223
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [BUG] Specific case caused by !Redraw if in Measure in IfCondition

Post by Yincognito »

Active Colors wrote: July 26th, 2020, 12:55 pmYincognito, from my experience with the skin I was working, showing meter group comes first and then udating it is the second, otherwise it is not displayed properly unless it is later updated.
I guess we'll have to agree to disagree here, when talking about "normal" meters. However, if it's about background meters and adapting them to the other meters, that of course changes things. Therefore:
jsmorley wrote: July 26th, 2020, 1:18 pmChew on that last bit. It's the reason why you are still getting the "chopped off" effect when you include a !Redraw bang in your measure. What you really want to do is to update all meters "twice", to ensure that the background meter has the current values for the meters after it in the skin, THEN let the skin redraw the window naturally.
Or, my preferred solution for this, used in my skins to draw a bevel of custom width: draw the meters transparently first, followed by drawing the background based on their dimensions and then update / draw the meters normally afterwards. This has the benefit of update / drawing the meters one additional time just once (UpdateDivider=-1), at skin load / refresh. I don't need to double-update or double redrawing them afterwards.
User avatar
jsmorley
Developer
Posts: 21235
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: [BUG] Specific case caused by !Redraw if in Measure in IfCondition

Post by jsmorley »

Yincognito wrote: July 26th, 2020, 2:47 pm Or, my preferred solution for this, used in my skins to draw a bevel of custom width: draw the meters transparently first, followed by drawing the background based on their dimensions and then update / draw the meters normally afterwards. This has the benefit of update / drawing the meters one additional time just once (UpdateDivider=-1), at skin load / refresh. I don't need to double-update or double redrawing them afterwards.
My example and explanation was based on an assumption that the size of the "foreground" meters are not static, and can change dynamically based on measure values, potentially on each skin update. The end-goal is to not have the background meter always be "one update behind".

There are certainly other approaches, and other places you can put the "action" to drive this, maybe in an OnChangeAction on some measure that is driving the size of the foreground meters, but at the end of the day, you are still going to want to update the "foreground" meters, then update the "background" meter, then let the skin redraw.
User avatar
balala
Rainmeter Sage
Posts: 11192
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: [BUG] Specific case caused by !Redraw if in Measure in IfCondition

Post by balala »

jsmorley wrote: July 26th, 2020, 1:18 pm However, there is just no point in doing !Redraw if you don't also have some change to something visible. You will always use !Redraw in combination with one or more !UpdateMeter bangs.
I think the !Redraw bang makes sens in combination not just with !UpdateMeter, but with !ShowMeter / !HideMeter / !ToggleMeter as well. When a meter is shown / hidden, might be a good idea to immediately redraw the skin, to get it appearing / disappearing immediately, not just on next update cycle.
User avatar
jsmorley
Developer
Posts: 21235
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: [BUG] Specific case caused by !Redraw if in Measure in IfCondition

Post by jsmorley »

balala wrote: July 26th, 2020, 4:03 pm I think the !Redraw bang makes sens in combination not just with !UpdateMeter, but with !ShowMeter / !HideMeter / !ToggleMeter as well. When a meter is shown / hidden, might be a good idea to immediately redraw the skin, to get it appearing / disappearing immediately, not just on next update cycle.
Yes, agreed.
User avatar
Yincognito
Posts: 2223
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [BUG] Specific case caused by !Redraw if in Measure in IfCondition

Post by Yincognito »

jsmorley wrote: July 26th, 2020, 3:01 pm My example and explanation was based on an assumption that the size of the "foreground" meters are not static, and can change dynamically based on measure values, potentially on each skin update. The end-goal is to not have the background meter always be "one update behind".

There are certainly other approaches, and other places you can put the "action" to drive this, maybe in an OnChangeAction on some measure that is driving the size of the foreground meters, but at the end of the day, you are still going to want to update the "foreground" meters, then update the "background" meter, then let the skin redraw.
You're probably right, as my skins are what I like to call "semi-dynamic", i.e. technically dynamic, but constrained to a size depending on the constituent meters' dimensions (in other words, not entirely dynamic, in the strict sense). However, it's just a matter of UpdateDivider, really:

Code: Select all

[Variables]
MeterWidth=[MeterInvisible:W]
MeterHeight=[MeterInvisible:H]
SkinWidth=(#MeterWidth#)
SkinHeight=(#MeterHeight#)
FontSize=0

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

---Measures---

[MeasureFontSize]
Measure=Calc
Formula=((MeasureFontSize+1)%10)
OnUpdateAction=[!SetVariable FontSize (14+[MeasureFontSize])]
DynamicVariables=1

---Meters---

[MeterInvisible]
Meter=String
FontFace=Tahoma
FontSize=#FontSize#
FontColor=0,0,0,0
StringEffect=Shadow
FontEffectColor=0,0,0,0
AntiAlias=1
Text="Some Meters Here"
;UpdateDivider=-1
DynamicVariables=1

[MeterBackground]
Meter=Shape
Shape=Rectangle 0,0,#SkinWidth#,#SkinHeight# | StrokeWidth 0 | Fill Color 47,47,47,255
;UpdateDivider=-1
DynamicVariables=1

[MeterVisible]
Meter=String
FontFace=Tahoma
FontSize=#FontSize#
FontColor=255,255,255,255
StringEffect=Shadow
FontEffectColor=0,0,0,255
AntiAlias=1
Text="Some Meters Here"
DynamicVariables=1
Yes, like you said, it's a matter of updating and redrawing. What I meant was that I would get rid of the manual update and redrawing and just let Rainmeter's update rate handle that. I know you mentioned this about redrawing too, but I mean let everything be handled by Rainmeter, tweaking things just by the order you place the meters in.