It is currently March 28th, 2024, 9:54 pm

New Container option

General topics related to Rainmeter.
User avatar
balala
Rainmeter Sage
Posts: 16110
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Test of new Container option

Post by balala »

jsmorley wrote: November 24th, 2018, 1:41 pm I have no expectation that Container is going to work well with TransformationMatrix. The core of the issue is that Container is entirely based on the W and H of the meter being used as a container, and TransformationMatrix does not alter the meter shape or size when it transforms the stuff in the meter. There might be some limited success with scale, as long as you scale the W and H along with any change to content, but I can't imagine that any rotate or skew is ever going to work right.

I'm no expert on TransformationMatrix, and in fact avoid it like the plague, as I find it really hard to wrap my head around. (that's just me...). I'd be delighted if we could get some examples of what works and what doesn't work. Not so much to "fix" anything, as we may be pretty limited in what we can do, but to set some "rules" that can be documented.
TransformationMatrix indeed isn't something too simple, but...
It seems finally raiguard had at least partially right. Obviously I knew that when applied, the TransformationMatrix changes only the visibility of the meter, and the meter reacts on mouse over or click, as with not applied TransformationMatrix. However something weird is going on here: if a TransformationMatrix is applied to scale the container, the content is following the container IF it is reduced (scaled down), but it isn't IF the container is enlarged (scaled up). Here is a small demonstration:

Code: Select all

[Rainmeter]
AccurateText=1
Update=1000
SkinWidth=300
SkinHeight=300

[Variables]
Scale=1

[MeterBackground]
Meter=Image
SolidColor=0,0,0,120
X=0
Y=0
W=300
H=300
DynamicVariables=1
MouseScrollUpAction=[!SetVariable Scale "(#Scale#+0.25)"][!UpdateMeter *][!Redraw]
MouseScrollDownAction=[!SetVariable Scale "(#Scale#-0.25)"][!UpdateMeter *][!Redraw]

[MeterContainerVis]
Meter=Image
SolidColor=255,240,0,150
X=100
Y=100
W=100
H=100
TransformationMatrix=#Scale#;0;0;#Scale#;(150*(1-#Scale#));(150*(1-#Scale#))
DynamicVariables=1
;Hidden=1

[MeterContainer]
Meter=Image
SolidColor=255,0,0,150
X=100
Y=100
W=100
H=100
TransformationMatrix=#Scale#;0;0;#Scale#;(150*(1-#Scale#));(150*(1-#Scale#))
DynamicVariables=1

[MeterContaint]
Meter=String
X=50
Y=50
FontColor=255,255,255
FontSize=24
StringAlign=CenterCenter
StringStyle=BOLD
AntiAlias=1
Text=Some text
Container=MeterContainer

[MeterScale]
Meter=STRING
MeasureName=MeasureUpdateDate
MeasureName2=MeasureTimeSec
X=0
Y=0
Padding=15,5,15,5
FontColor=220,220,220
SolidColor=0,0,0,150
FontSize=8
FontFace=Segoe UI
StringStyle=BOLD
StringAlign=LEFT
AntiAlias=1
Text=#Scale#
DynamicVariables=1
This is what you get using the above code:
Image
There are two identical Image meters: [MeterContainerVis] and [MeterContainer]. The second is the container, but because if this is used as container it isn1t visible, I added the first one, to can see where and how large is the container.
See that if you scroll down and the container is scaled down, the string follows it: only its part contained inside of the scaled down part of the container remains visible, but if on the other hand, you scale it up, only the initial part of the string remains visible, this time it doesn't follow the container.
As I said, I find this weird. I have no explanation. There is any?
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Test of new Container option

Post by jsmorley »

balala wrote: November 24th, 2018, 7:42 pm TransformationMatrix indeed isn't something too simple, but...
It seems finally raiguard had at least partially right. Obviously I knew that when applied, the TransformationMatrix changes only the visibility of the meter, and the meter reacts on mouse over or click, as with not applied TransformationMatrix. However something weird is going on here: if a TransformationMatrix is applied to scale the container, the content is following the container IF it is reduced (scaled down), but it isn't IF the container is enlarged (scaled up). Here is a small demonstration:

<snip>

There are two identical Image meters: [MeterContainerVis] and [MeterContainer]. The second is the container, but because if this is used as container it isn1t visible, I added the first one, to can see where and how large is the container.
See that if you scroll down and the container is scaled down, the string follows it: only its part contained inside of the scaled down part of the container remains visible, but if on the other hand, you scale it up, only the initial part of the string remains visible, this time it doesn't follow the container.
As I said, I find this weird. I have no explanation. There is any?
It is because TransformationMatrix does NOT change the size or shape of any meter it is used in. It only acts on what is inside the meter, and has no effect on the meter itself. This can, and often will, mean that the stuff you are transforming will extend outside the W and H defined for the meter. This is fine visually most of the time, but impacts things like mouse detection, and in this case, the way "content" is masked into the container, since the Container functionality is entirely dependent on the W and H of the container meter.

Code: Select all

[Rainmeter]
AccurateText=1
Update=1000
SkinWidth=300
SkinHeight=300

[Variables]
Scale=1

[MeterBackground]
Meter=Image
SolidColor=0,0,0,120
X=0
Y=0
W=300
H=300
DynamicVariables=1
MouseScrollUpAction=[!SetVariable Scale "(#Scale#+0.25)"][!UpdateMeter *][!Redraw]
MouseScrollDownAction=[!SetVariable Scale "(#Scale#-0.25)"][!UpdateMeter *][!Redraw]

[MeterContainerVis]
Meter=Image
SolidColor=255,240,0,150
X=100
Y=100
W=100
H=100
TransformationMatrix=#Scale#;0;0;#Scale#;(150*(1-#Scale#));(150*(1-#Scale#))
DynamicVariables=1
;Hidden=1

[MeterContainer]
Meter=Image
SolidColor=255,0,0,150
X=100
Y=100
W=100
H=100
TransformationMatrix=#Scale#;0;0;#Scale#;(150*(1-#Scale#));(150*(1-#Scale#))
DynamicVariables=1

[MeterContaint]
Meter=String
X=50
Y=50
FontColor=255,255,255
FontSize=24
StringAlign=CenterCenter
StringStyle=BOLD
AntiAlias=1
Text=Some text
Container=MeterContainer

[MeterScale]
Meter=STRING
MeasureName=MeasureUpdateDate
MeasureName2=MeasureTimeSec
X=0
Y=0
Padding=15,5,15,5
FontColor=220,220,220
SolidColor=0,0,0,150
FontSize=8
FontFace=Segoe UI
StringStyle=BOLD
StringAlign=LEFT
AntiAlias=1
Text=#Scale#
DynamicVariables=1

[MeterContainerSize]
Meter=String
Y=5R
Padding=15,5,15,5
FontColor=220,220,220
SolidColor=0,0,0,150
FontSize=8
FontFace=Segoe UI
StringStyle=BOLD
StringAlign=LEFT
AntiAlias=1
Text=[MeterContainer:W]
DynamicVariables=1
GIF.gif

Note the "size" of the container meter indicated below the "scale" value in the upper left. It never changes...
You do not have the required permissions to view the files attached to this post.
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Test of new Container option

Post by jsmorley »

And before you try to fix this by scaling the W and H of the container meter along with the contents, there is a known "bug" in that today, that we will be addressing in the coming week or so. Dynamically changing the "size" of a container gives unexpected and unreliable results with the content today.
User avatar
balala
Rainmeter Sage
Posts: 16110
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Test of new Container option

Post by balala »

jsmorley wrote: November 28th, 2018, 3:04 pm It is because TransformationMatrix does NOT change the size or shape of any meter it is used in.
Right, this is ok and I knew this. Also Ok is the fact that the size of the container doesn't change:
jsmorley wrote: November 28th, 2018, 3:04 pm Note the "size" of the container meter indicated below the "scale" value in the upper left. It never changes...
What intrigue me is that if the container is reduced (scaled down) with TransformationMatrix, the content follows it and remain visible only the parts of it placed inside of the scaled container, while if the container is enlarged (scaled up), this doesn't happening. In this case the visible part of the content doesn't follow the size of the container.
User avatar
balala
Rainmeter Sage
Posts: 16110
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Test of new Container option

Post by balala »

jsmorley wrote: November 28th, 2018, 3:14 pm And before you try to fix this by scaling the W and H of the container meter along with contents, there is a known "bug" in that today, that we will be addressing in the coming week or so. Dynamically changing the "size" of a container gives unexpected and unreliable results with the content today.
:thumbup:
All right! I also noticed this, but didn't realize this is a bug, just thought I do something wrong. Now it's much clearer what has gone on.
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Test of new Container option

Post by jsmorley »

balala wrote: November 28th, 2018, 3:17 pm Right, this is ok and I knew this. Also Ok is the fact that the size of the container doesn't change:

What intrigue me is that if the container is reduced (scaled down) with TransformationMatrix, the content follows it and remain visible only the parts of it placed inside of the scaled container, while if the container is enlarged (scaled up), this doesn't happening. In this case the visible part of the content doesn't follow the size of the container.
In this example, the W and H size of the container never changes. That is a limitation of TransformationMatrix.

However, the visible "solid" pixels of the container meter are changed by the scaling, so the "image" inside the container W and H is scaled down when you scroll down on the skin. The contents are masked into the container meter with the following rules.

1) The content is "constrained" by the W and H of the container meter. Anything outside the W and H of the container will be truncated.

2) The content is "masked" into "solid" pixels of the container meter.

So what is going on when you scale "down" is that the W and H of the container stays the same. 100 X 100. However, the visible shape inside the meter is scaled down and is smaller. Thus the content is only masked into the smaller shape, where the pixels are "solid" in the meter. So even though the meter is 100 X 100, the shape inside it may be 50 X 50, and the string is only drawn on those 50 X 50 solid pixels.

So it appears to be scaling down the size of the content, but it really isn't. It's just not "drawing" content on transparent pixels of the container.

While we will endeavor to fix the issue with the W and H of a container dynamically changing, I caution that in my view, It is going to be challenging, if not impossible, to get TransformationMatrix working and playing well with this functionality. I'm pretty sure there will be a way to have "scale" work ok, as long as you alter the container W and H at the same time, but I'm fearful that transforms that alter the "shape" of the meter contents, like "rotate" and "skew", are going to be difficult to get right.
User avatar
balala
Rainmeter Sage
Posts: 16110
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Test of new Container option

Post by balala »

jsmorley wrote: November 28th, 2018, 3:30 pm In this example, the W and H size of the container never changes. That is a limitation of TransformationMatrix.

However, the visible "solid" pixels of the container meter are changed by the scaling, so the "image" inside the container W and H is scaled down when you scroll down on the skin. The contents are masked into the container meter with the following rules.

1) The content is "constrained" by the W and H of the container meter. Anything outside the W and H of the container will be truncated.

2) The content is "masked" into "solid" pixels of the container meter.

So what is going on when you scale "down" is that the W and H of the container stays the same. 100 X 100. However, the visible shape inside the meter is scaled down and is smaller. Thus the content is only masked into the smaller shape, where the pixels are "solid" in the meter. So even though the meter is 100 X 100, the shape inside it may be 50 X 50, and the string is only drawn on those 50 X 50 solid pixels.

So it appears to be scaling down the size of the content, but it really isn't. It's just not "drawing" content on transparent pixels of the container.
Thanks, I think I understood now. Will make a few tests, but I hope I understood. Good point, by the way...
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Test of new Container option

Post by jsmorley »

balala wrote: November 28th, 2018, 3:41 pm Thanks, I think I understood now. Will make a few tests, but I hope I understood. Good point, by the way...
Difficult to test right now, until we fix that "bug" with dynamically changing the W and H of a container meter. Today, the "content" does not react well to this change.
User avatar
balala
Rainmeter Sage
Posts: 16110
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Test of new Container option

Post by balala »

jsmorley wrote: November 28th, 2018, 3:45 pm Difficult to test right now, until we fix that "bug" with dynamically changing the W and H of a container meter. Today, the "content" does not react well to this change.
For now I'll play a little bit with the TransformationMatrix, then when the bug fixed, will study resizing the container modifying its size. There are infinite possibilities probably. :thumbup:
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Test of new Container option

Post by jsmorley »

Ok, we have corrected the outstanding issues we know about, and have moved this into the normal "beta" cycle for Rainmeter.

1) Corrected an issue when a "container" meter is resized dynamically.
2) Corrected an issue of duplicate "masking" when a "content" meter is switched dynamically from one "container" meter to another.
3) Corrected an issue when a "container" meter is "hidden", or otherwise has either W or H set to zero.

Get the latest Rainmeter 4.3 beta, r3266 as of this writing, at https://www.rainmeter.net

The documentation and example .rmskin for Container are at https://docs.rainmeter.net/manual-beta/meters/general-options/container/

Please continue to beat this up. We will be delighted (well, ok, not delighted exactly) if you can find and report any other bugs we may have missed, and as always are very interested to see what clever stuff you do with this new functionality.