Transformation matrix on scaling + resource usage

[Jax]

Hey

I'm currently working on a resizable menu, and had my fontsize scaled with (size*scale), which works, but creates this issue where the text would only react to certain whole numbers of fontsize. Therefore I wanted to create smooth resizing with transformation matrix.

Scaling with font size:

2021-08-10 12-56-13.gif

Current test code with transformation matrix scaling:

Code: Select all

[Rainmeter]
SkinWidth=700
SkinHeight=400

[Variables]
Set.P=(20*[Set.S])
Scroll=0

[Set.S]
Measure=Calc
Formula=1

[Set.String:S]
AntiAlias=1
SolidColor=0,0,0,1
DynamicVariables=1

[Back]
Meter=String
W=700
H=400
SolidColor=255,255,255,50

[Class.Text1]
Meter=String
MeterStyle=Set.String:S
Text=JaxCore3
X=(#Set.P#)
Y=(#Set.P#+10*[Set.S]+#Scroll#)
FontSize=60
FontFace=Poppins SemiBold
StringAlign=LeftTop
InlineSetting=GradientColor | 180 | CC1C15 ; 0.0 | FF700F ; 1.0
TransformationMatrix=[Set.S];0;0;[Set.S];((1-[Set.S])*[#CURRENTSECTION#:X]);((1-[Set.S])*[#CURRENTSECTION#:Y])

[Class.Text2]
Meter=String
MeterStyle=Set.String:S
Text=Welcome to JaxOriginals' configuration hub.
X=r
Y=R
FontSize=16
TransformationMatrix=[Set.S];0;0;[Set.S];((1-[Set.S])*[#CURRENTSECTION#:X]);((1-[Set.S])*[#CURRENTSECTION#:Y])
StringAlign=LeftTop
FontColor=#Set.SubText_Color#

With Set.S as 1, everything is positions as they should be, but with 0.5 the relative positions are not working properly.
Another thing I am curious about is would transformation matrix take up a high amount of resource usage? If that is the case I would not use that for scaling then.

[death.crafter]

With Set.S as 1, everything is positions as they should be, but with 0.5 the relative positions are not working properly.
Another thing I am curious about is would transformation matrix take up a high amount of resource usage? If that is the case I would not use that for scaling then.

This is actually a nice way to scale things.

But while transformation matrix scales things up or down, the size of the meter stays same. So something like this (see the Y):

Code: Select all

[Class.Text2]
Meter=String
MeterStyle=Set.String:S
Text=Welcome to JaxOriginals' configuration hub.
X=r
Y=([Class.Text1:H]*[Set.S]-[Class.Text1:H])R
FontSize=16
TransformationMatrix=[Set.S];0;0;[Set.S];((1-[Set.S])*[#CURRENTSECTION#:X]);((1-[Set.S])*[#CURRENTSECTION#:Y])
StringAlign=LeftTop
FontColor=#Set.SubText_Color#

will work.

And I don't think transformation matrix has anything to do with resource usage.

[Jax]

But while transformation matrix scales things up or down, the size of the meter stays same. So something like this (see the Y):

I see, thanks for the solution.

I'll see if using too much tm would use up resources.

[Yincognito]

And I don't think transformation matrix has anything to do with resource usage.

It does, especially if you do it on scaled larger images where a low update rate is also involved. For simple / smaller cases like this though, the impact is negligible.

[Jax]

It does, especially if you do it on scaled larger images where a low update rate is also involved. For simple / smaller cases like this though, the impact is negligible.

Good to know

[balala]

It does, especially if you do it on scaled larger images where a low update rate is also involved. For simple / smaller cases like this though, the impact is negligible.

I doubt that on modern computers Rainmeter has an important resource usage, excepting some cases (for instance when using some visualizer skins, with very low Update, in which case it really can have). Otherwise today's computers are powerful enough not to be affected too much by Rainmeter. My opinion, at least...

[Yincognito]

I doubt that on modern computers Rainmeter has an important resource usage, excepting some cases (for instance when using some visualizer skins, with very low Update, in which case it really can have). Otherwise today's computers are powerful enough not to be affected too much by Rainmeter. My opinion, at least...

Let me see if I understood correctly what you said:

- just because your computer is a modern one and mine is not (which is not what this is about)
- except the case of "some" low update rate visualisers (which is what I just said above, except that it's not only about visualisers, but about any Rainmeter skin that uses larger image resizing/transforming coupled with low update rates, including such skins that use your beloved TransformationMatrix)
- it's ok for Rainmeter to use a ton of CPU even though it could use less through more efficient alternatives (which is basically like buying a car that uses 10 litres of fuel instead of one using just 5 to achieve the same purpose)
- because you're of the opinion that on your computer this is tolerable (which isn't really about opinions, but about factual measurements ... in Rainmeter itself)

Did I got it right?

In case you still are of the same opinion, try this (right click for the context menu, choose any option ending in TranMx from the Custom Skin Actions menu, scroll up on the Earth image to scale the skin to a larger size, and optionally middle click to show the information panels followed by scrolling on the TILT value) at your own risk, and watch your CPU burn, LOL: Rotating 3D Earth 3.0.0

The ONLY difference compared to the previous versions (which took much less CPU to run) was that I resized the original image in the skin scaling process, either through TransformationMatrix or setting a dynamic W and H (the latter for the ImageRotate case, which requires that as you know). The current version, without the (beautiful but suicidal) scaling still takes more CPU compared to the usual 1%, but only for certain implementation methods (including some TransformationMatrix ones), simply because there is scaling in that option as well: Rotating 3D Earth 4.0.0

I'll let you draw the conclusion...

P.S. Maybe I should repeat, in case it wasn't clear yet: it's only in certain scenarios that high CPU usage is involved. For simpler/smaller stuff, TransformationMatrix (and Rainmeter itself) are perfectly fine - I never disagreed with this.

[jsmorley]

"My computer is bigger than your computer". Is that what you kids are calling it these days?

[SilverAzide]

I *thought* I had a "modern computer" until Microsoft came out with their Windows 11 specs. Stupid me...

[balala]

Let me see if I understood correctly what you said:

- just because your computer is a modern one and mine is not (which is not what this is about)
- except the case of "some" low update rate visualisers (which is what I just said above, except that it's not only about visualisers, but about any Rainmeter skin that uses larger image resizing/transforming coupled with low update rates, including such skins that use your beloved TransformationMatrix)
- it's ok for Rainmeter to use a ton of CPU even though it could use less through more efficient alternatives (which is basically like buying a car that uses 10 litres of fuel instead of one using just 5 to achieve the same purpose)
- because you're of the opinion that on your computer this is tolerable (which isn't really about opinions, but about factual measurements ... in Rainmeter itself)

I don't know your computer, but I never brag with mine. Sorry, but I doubt I said anything "wrong" about yours.
In a normal Rainmeter usage on a decent computer (not yours or mine or anyone, but a decent one), Rainmeter doesn't consume too much resources. Still saying: this is my opinion. I sustain it based on my experience.
No more comments on my side...