A) Padding increases the size and shape of the overall meter.
B) When ONLY W or H is defined, then PreserveAspectRatio is forced to "1".
So what happens, while a bit weird, is not unexpected.
1) You have an image that has a particular aspect ratio. It is bigger in W than it is in H or visa versa.
2) Then you add an equal amount of Padding around all sides of the starting meter, which changes the aspect ratio of the overall meter. You didn't add a proportional amount of padding to the top and bottom based on the aspect ratio of the image. So "relatively more" size was added in one direction. It is having proportionally more added to the "smaller" side in a sense.
3) Then the image is resized to whatever you set W or H to.
4) The aspect ratio of the overall meter is "preserved", causing the image embedded in the center of the overall meter to appear distorted.
This all comes down to "when" the various elements of this stuff happens. The resizing of the image based on the overall size and aspect ratio of the meter is the very last thing that is done, and in fact is done in the "redraw" portion of the update cycle, not when the meter itself is "updated".
So the W is applied to just the "image", while the PreserveAspectRatio is applied to the entire "meter". What you really mean to have happen is that the image is resized to the W, preserving the aspect ratio, and THEN the equal amount of padding is added. Doesn't work that way. The padding is added before the sizing, and more importantly, the preservation of the aspect ratio of the meter, is done.
I would be hesitant to use Padding with images that you resize, as this is going to be a bit hard to manage properly.
I could easily argue against this behavior, but things in Rainmeter have to happen in some "order". Some things have to happen "first" and some "second". This is how it ended up, and I suspect we have to live with it for backwards compatibility reasons.
jsmorley wrote: ↑December 30th, 2019, 7:58 pmI suspect we have to live with it for backwards compatibility reasons.
Backwards Compatibility strikes again!
Only problem I see is relative positioning but that can be resolved by #Pad#r/R (custom one on the first meter after if using MeterStyles)
Good enough fix
The only other issue is that if the image is dynamically changed to something with a different aspect ratio, the background Shape will be one update behind in sizing itself. So for one second it will be wrong, then correct itself.
jsmorley wrote: ↑December 30th, 2019, 8:36 pm
The only other issue is that if the image is dynamically changed to something with a different aspect ratio, the background Shape will be one update behind in sizing itself. So for one second it will be wrong, then correct itself.
That's why I always do two !UpdateMeter bangs, then a !Redraw. Anyways, I fail to see how fixing this bug would affect backwards compatibility. I mean, I don't see anybody using the padding option to deliberately mess up an image's aspect ratio.