It is currently May 17th, 2022, 11:36 am

[BUG OR NOT] Abnormally moving text relative to an image meter

Get help with creating, editing & fixing problems with skins
User avatar
Yincognito
Rainmeter Sage
Posts: 4694
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

[BUG OR NOT] Abnormally moving text relative to an image meter

Post by Yincognito »

I've been struggling with this for days in one of my skins and thought I was the one having a mistake in my code, but it turns out it was all Rainmeter's "modus operandi". This self explanatory skin proves it (I'm assuming you still have the default Illustro skin in your Rainmeter skins folder):

Code: Select all

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

---Measures---

---Meters---

[MeterImage]
Meter=Image
ImageName=
;#SKINSPATH#illustro\@Resources\Background.png
X=2
Y=2
;W=0
Padding=5,5,5,5
DynamicVariables=1

[MeterString]
Meter=String
FontFace=Consolas
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
AntiAlias=1
X=0R
Text="Should this text move if it's positioned relative to a dynamic, dimensionless image meter that uses padding?#CRLF#Stopping this behavior requires static variables, no padding, or setting a valid ImageName / W on the meter."
DynamicVariables=1
So:
- why is the text moving, since the actual position of the image meter (i.e. X and Y, but also W and H) is static?
- how can one "fix" this abnormal behavior, without changing the options that solve this when commented (i.e. dynamic variables, W, padding and ImageName)?
- is this a bug or is it supposed to happen (because the latter makes no sense, in my view)?
Last edited by Yincognito on February 28th, 2020, 11:04 pm, edited 1 time in total.
User avatar
jsmorley
Developer
Posts: 22519
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: [BUG OR NOT] Abnormally moving image meter

Post by jsmorley »

If you add SolidColor=255,0,0,100 to the Image meter, you will find that the issue is that the Padding=5,5,5,5 is being added to itself on each update. This only happens if the Image meter has a W and H that is not defined. So the String meter is not "moving", but being "pushed".

The Image "container" starts as with both W and H as undefined, and there is no actual ImageName to give the meter any size. Then Padding adds 5 to each, and the container is 10X10. On the next update, 5 more is added to the container by the Padding, and so on. Forever.

This doesn't happen if you define any value for W and H on the Image meter, even if it is a static "0". It's not about zero, it's about "undefined".

It has to do with the combination of an undefined size, Padding, and DynamicVariables.

My advice would be to avoid have an Image meter that in a sense just doesn't exist. There is no ImageName, and no W/H/SolidColor, there is just nothing that gives Rainmeter something to grab onto with this meter.

What is happening is that Rainmeter sees the entirely undefined size. What it then wants to do is "figure out" the size based on the ImageName. Can't do that either. So the size REMAINS "undefined", not really "zero". Then Padding is added to the container after all that. Then on the next update, Rainmeter still sees the container as undefined, based on the meter options, but in reality it is 10, due to the Padding. So the size remains "undefined", and Padding is added again.

I guess this is a bug. As is often the case, it has to do with the "order" that things are done in.
User avatar
Yincognito
Rainmeter Sage
Posts: 4694
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [BUG OR NOT] Abnormally moving image meter

Post by Yincognito »

jsmorley wrote: February 27th, 2020, 1:53 pm[...] you will find that the issue is that the Padding=5,5,5,5 is being added to itself on each update. This only happens if the Image meter has a W and H that is not defined. So the String meter is not "moving", but being "pushed". [...] This doesn't happen if you define any value for W and H on the Image meter, even if it is a static "0". It has to do with the combination of an undefined size, Padding, and DynamicVariables.
Yes, I figured the above already. I used "move" instead of "push" for better clarity. :)
jsmorley wrote: February 27th, 2020, 1:53 pmI guess this is a bug.
Thanks for giving a verdict - I like to know where I stand. Now that being said, it's no pressure fixing it, as in the meantime, the workaound I found is to just use the left and top padding values as X and Y for the image meter, and add the right and bottom padding to the text meter instead.
jsmorley wrote: February 27th, 2020, 1:53 pmMy advice would be to avoid have an Image meter that in a sense just doesn't exist. There is no ImageName, and no W/H/SolidColor, there is just nothing that gives Rainmeter something to grab onto with this meter.
I guess I could use a "default" image when the image meter is "blank", but I'd rather not. This has to do with my custom tooltip skin, where titles have to be put where needed even if there isn't a "tooltip icon" at their left. Plus, I guess I can't make a 0 width and 0 height image in any software, LOL.

Anyway, as I said, I'll use the above workaround in the meantime, as it doesn't produce any side issues (so far; hopefully it never will).
User avatar
Yincognito
Rainmeter Sage
Posts: 4694
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [BUG OR NOT] Abnormally moving image meter

Post by Yincognito »

jsmorley wrote: February 27th, 2020, 1:53 pmWhat is happening is that Rainmeter sees the entirely undefined size. What it then wants to do is "figure out" the size based on the ImageName. Can't do that either. So the size REMAINS "undefined", not really "zero". Then Padding is added to the container after all that. Then on the next update, Rainmeter still sees the container as undefined, based on the meter options, but in reality it is 10, due to the Padding. So the size remains "undefined", and Padding is added again.
That's interesting. I thought the padding was somehow (internally) considered "out of the actual meter", despite being included in the [Meter:W] and [Meter:H] values, but what you said makes more sense than my wild guess. In other words, I thought Rainmeter could figure out that when there's no ImageName (or ImagePath) the image dimensions are 0, but apparently I was wrong.
Last edited by Yincognito on February 27th, 2020, 2:19 pm, edited 1 time in total.
User avatar
jsmorley
Developer
Posts: 22519
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: [BUG OR NOT] Abnormally moving image meter

Post by jsmorley »

Yeah, I think Photoshop is telling you something when it refuses to create an image that is 0x0... ;-)
User avatar
Yincognito
Rainmeter Sage
Posts: 4694
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [BUG OR NOT] Abnormally moving image meter

Post by Yincognito »

jsmorley wrote: February 27th, 2020, 2:18 pm Yeah, I think Photoshop is telling you something when it refuses to create an image that is 0x0... ;-)
Yeah, something like ... :jawdrop , are you serious?! O.O
User avatar
jsmorley
Developer
Posts: 22519
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: [BUG OR NOT] Abnormally moving image meter

Post by jsmorley »

Yincognito wrote: February 27th, 2020, 2:17 pm That's interesting. I thought the padding was somehow (internally) considered "out of the actual meter", despite being included in the [Meter:W] and [Meter:H] values, but what you said makes more sense than my wild guess. In other words, I thought Rainmeter could figure out that when there's no ImageName (or ImagePath) the image dimensions are 0, but apparently I was wrong.
It's the combination of "undefined" and DyamicVariables that is the culprit at the end of the day. The DynamicVariables tells Rainmeter to entirely "reconsider" the meter options on each update, and so it more or less "starts over", and says "OK, I simply can't figure out the size of this image, so I will just leave it as undefined.". It's not looking at the size of the "meter" at that point, it's job it to "set" the size of the meter base on the image, not "read" it. Meanwhile the actual size of the "meter" (not the "image") is 10, and Padding is added to that. Spit, rinse, and repeat.

I'm not sure it can be any other way. If the actual size of the meter container is "considered" on each update with DynamicVariables, then the Padding will ALWAYS be added over and over again on any meter that has an "implied" W and H based on the contents, not the actual setting of W and H options.
User avatar
Yincognito
Rainmeter Sage
Posts: 4694
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [BUG OR NOT] Abnormally moving image meter

Post by Yincognito »

jsmorley wrote: February 27th, 2020, 2:24 pm It's the combination of "undefined" and DyamicVariables that is the culprit at the end of the day. The DynamicVariables tells Rainmeter to entirely "reconsider" the meter options on each update, and so it more or less "starts over", and says "OK, I simply can't figure out the size of this image, so I will just leave it as undefined.". It's not looking at the size of the "meter" at that point, it's job it to "set" the size of the meter base on the image, not "read" it. Meanwhile the actual size of the "meter" (not the "image") is 10, and Padding is added to that. Spit, rinse, and repeat.
Indeed - thanks for explaining the inner workings of it, I like that.

Now if you permit, a little bit off-topic question, somewhat related to this: does (#TextSize#/72*96)/2 (where #TextSize# is the actual FontSize option's value) accurately determine the half-height of the (exclusive, no padding considered) "text frame" in all cases and all fonts? Of course, the 72 and 96 values are presumably the real values of PointsPerInch and PixelsPerInchY. I want to position the text right at the vertical middle of the image (if it exists) and at the vertical middle of "itself" (i.e. the text), if the image doesn't exist. Since to know the height of a meter, that meter has to be first drawn, could this be a reliable way of finding out the height of the text (padding excluded, since it's added afterwards) before its drawing, given one knows the exact values of the display's PointsPerInch and PixelsPerInchY? Side question: there isn't a way to find out PixelsPerInchX and PixelsPerInchY in Rainmeter, is it?
User avatar
jsmorley
Developer
Posts: 22519
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: [BUG OR NOT] Abnormally moving image meter

Post by jsmorley »

I don't think you are going to be successful in setting the "position" of a string of text based on the value of the FontSize option. Font glyphs are not at all some "standard" thing, and many fonts have more or less "slack space" above and or below the character.

You might have some success with this when using a single, "known" font, but even then it is going to be some trial-and-error on your part to find the right formulas.

And no, Rainmeter has no visibility into the metrics of any font, nor the Windows settings for DPI.

We are planning to look into dealing with DPI in a more robust way in the future, to help with "scaling" somewhat, but that is not likely to ever have anything to do with "points" in a font. As I said, "points" is only somewhat and inexactly related to "position" in any case.
User avatar
Yincognito
Rainmeter Sage
Posts: 4694
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [BUG OR NOT] Abnormally moving image meter

Post by Yincognito »

jsmorley wrote: February 27th, 2020, 2:46 pm I don't think you are going to be successful in setting the "position" of a string of text based on the value of the FontSize option. Font glyphs are not at all some "standard" thing, and many fonts have more or less "slack space" above and or below the character.

And no, Rainmeter has no visibility into the metrics of any font, nor the Windows settings for DPI.

We are planning to look into dealing with DPI in a more robust way in the future, to help with "scaling" somewhat, but that is not likely to ever have anything to do with "points" in a font. As I said, "points" is only somewhat and inexactly related to "position" in any case.
Ok, got it - thanks for making this clear. ;-)