Extra Container Mask Error and Inconsistency

[Mithyr Sar]

(Edit) Yincognito's post brought up an issue that I knew of but only mentioned obliquely in the second paragraph.
Warning: The original skin uses 53 large images and 9 masks to accomplish the effect of the script it's using. All of this information is computationally heavyweight. This is why I will refer to it as "too math intensive to work." The original skin will still likely run even a high spec CPU up to 100% and monopolize a majority of resources and compute time. The "-edit" version attached uses only a few objects and lifts my CPU about 12% over the skin unloaded.(/EDIT)

I am new to using and coding Rainmeter skins.

I had an idea for a live visualization that I wanted to create and Rainmeter seemed to be a possible means. After I've managed an implementation, I think it's too math intensive to work as is. I might have to come up with a alternate means of realizing it. However it did produce a curious error that I have been unable to find a reason for or a fix.

Every image object in the skin has it's own position/spin/rate and the whole has a rate of it's own. As I started implementing the arcs, essentially masked rings, the first went without issue. The second however, there seems to be a second unimplemented container that further masks it solely to the upper left quadrant of the rest of the whole. I finished the whole to see it's effect.

There are 3 classes of arcs, three cases of each. Two of the classes, a total of 6 arcs, work fine. Each of the 3 based on the one that exhibited the first unimplemented mask error all have the same error, masked to the upper left quadrant (in code these are those meters noted and called some variation of "ring09"). The zip of my code is attached.

I've tested the mask without using it implemented as the container. I've attempted changing the name and position in code of the masks and meters involved. (EDIT)I've checked for mis-named code and curious characters as well, even though I used no snippets.(/EDIT) The only thing I have not tested is changing the size of the image files (increasing the matte edges). I have no idea why that would be pertinent.

Beyond that, I thank those who help in advance. Any help with suggestions also welcome.

[Yincognito]

After I've managed an implementation, I think it's too math intensive to work as is. I might have to come up with a alternate means of realizing it. However it did produce a curious error that I have been unable to find a reason for or a fix.

I would like to help you, although Lua is not exactly my favorite in Rainmeter, but ... I won't do it if it fries my CPU, LMAO. It goes to 98% usage in my case, so that's unnacceptable for me (thanks, Rainmeter, for letting me know that and the temps on the fly). In the very short time of running (I have no idea if it was enough), your skin didn't produce any errors.

I somehow doubt math intensiveness is the issue here, to me it looks like the approach itself is doomed to fail: you have huge images for this kind of process, a ton of masks, TransformationMatrix on every meter AND on top of that Lua scripts that dynamically change the said matrices and the images on every freaking measure updating every second!!! This is the ultimate CPU killer, really.

What you should do is simplify / reduce things in your skin so that other peple who still have computers instead of rockets in front of them to be able to try / debug this and figure out what should be done to solve the issue (if there is one, as I didn't quite get what seems to be the problem). Until then, I'll protect my CPU against your evil coronavirus!

[Mithyr Sar]

Thank you for loading it and trying it out and for your honest critique. It was careless of me not to be more specific. I have edited the original post with an appropriate warning up front.

I have also created a stripped down version that takes out most of the details of the finished unit. Using a few base rings and the lines ring, and speeding up the slow global rotation, you can see the first visible arc slowly disappearing behind an unimplemented container edge at 90 degrees global. Once the second arc spins up past 180 degrees global it starts appearing, then disappears at 90. The same for the third.

The original CPU heating example had 6 arcs that worked exactly as containers or masks are intended, but I can not figure out why these three are double masked this way.

I apologize again for the lack of disclosure in the first post, so much for first impressions.

[Yincognito]

Thank you for loading it and trying it out and for your honest critique. It was careless of me not to be more specific. I have edited the original post with an appropriate warning up front.

I have also created a stripped down version that takes out most of the details of the finished unit. Using a few base rings and the lines ring, and speeding up the slow global rotation, you can see the first visible arc slowly disappearing behind an unimplemented container edge at 90 degrees global. Once the second arc spins up past 180 degrees global it starts appearing, then disappears at 90. The same for the third.

The original CPU heating example had 6 arcs that worked exactly as containers or masks are intended, but I can not figure out why these three are double masked this way.

I apologize again for the lack of disclosure in the first post, so much for first impressions.

Now it's better, I can play with it. So, the problem is that those arcs are dissapearing, is that it? Because if it is, I think this is normal, since the mask09.png is 524x524, and anything outside it won't be visible, if it is set as the container of the meters holding those arcs (by the way, which meters are we talking about?). I used my "measurement skin" to demonstrate this, as it is set exactly to 524 px, 524 px from the 0 px, 0 px point on the screen - as you can see those arcs stop exactly when "touching" my measurement skin's frame:

Container Mask.jpg

In other words, I don't see this as "inconsistent" or "error". It's the expected behavior for a container to hide what's outside its W (width) and H (height), as mentioned in the manual (first bullet point).

P.S. Also, although I never tried it, I don't think that TransformationMatrix will change the "window size" of a container (or of any meter, for that matter), according to the same manual (the 2nd paragraph from the Note). TransformationMatrix is more of a visual illusion, as it scales, moves and skews things for the eye, but the meter that is subject to the transformation will keep its location and size, as far as I know (if anyone thinks differently, feel free to correct me). Therefore, I'm not sure that applying a transformation matrix to a container is of much use, other than possibly influencing the opaque pixels' location within the meter frame, I suppose.

NOTE: Aside from the actual topic in this thread, you might want to consider using Shape meters instead of images, as they are much more flexible and will probably ease the workload on the CPU massively (though the transformation matrices might still use some CPU, eventually).

[Mithyr Sar]

You showed me that it is working differently on your machine. Also you mentioned the implementation of TransformationMatrix being image output only and not window size, which I had a "working understanding" of as I used it. When I tried to set up some more examples with captures of my own, I am now getting new, different and not expected behaviors.

The masks were also transformed to mask specific parts of the arc, to move the circle into and out of eclipse but only ever show part of the arc. That rectangular container was not supposed to be there, not supposed to make them disappear. But it might be a matter of the matrix implementation, the image output versus the window.

For me to hash this out further I need to discover some more things on my side and take caps this time. Also I don't even know if I will take it much further, since I might not be able to get what I want without huge amounts of resources sunk into it or a completely different application framework.

Thank you for the help, I'll see if I can find out more before giving it a pass.

Maybe I'll get back sooner than later but I have a fer more projects i'm working on.

Thanks Yincogneto.

[Yincognito]

You showed me that it is working differently on your machine. Also you mentioned the implementation of TransformationMatrix being image output only and not window size, which I had a "working understanding" of as I used it. When I tried to set up some more examples with captures of my own, I am now getting new, different and not expected behaviors.

The masks were also transformed to mask specific parts of the arc, to move the circle into and out of eclipse but only ever show part of the arc. That rectangular container was not supposed to be there, not supposed to make them disappear. But it might be a matter of the matrix implementation, the image output versus the window.

For me to hash this out further I need to discover some more things on my side and take caps this time. Also I don't even know if I will take it much further, since I might not be able to get what I want without huge amounts of resources sunk into it or a completely different application framework.

Thank you for the help, I'll see if I can find out more before giving it a pass.

Maybe I'll get back sooner than later but I have a fer more projects i'm working on.

Thanks Yincogneto.

Take your time. And remember, using Shape meters is much simpler - you might not even need to use containers to achieve what you want using shapes (so I disagree with your "huge amounts of resources sunk into it" statement). Regarding my test, I slightly modified both the CenterX and CenterY to 360 in Variables.ini, in order for the whole thing to fit on my 1366x768 laptop monitor, that's all. I don't think these small changes significantly affected the skin's behavior, since I noticed those arcs dissapearing even before modifying those variables, around the same coordinates.

Anyway, good luck with your other projects and don't give up so easily on this one (especially if it can be approached in an easier way), assuming you have time for it.

[Mithyr Sar]

It's definitely the difference between the mask image WxH box oriented at 0,0 (since I applied the TransformationMatrix and did not modify the x,y of the image box) and the visible/transparent parts of the mask. The other masks have a very large native size and this is why they appeared to work properly.

Each mask is an image. Each mask image in this case is a square by dint of it containing a circular mask. The mask is a region of visible and transparent pixels, to show the visible bits and mask the transparent bits. The problem which is, as was stated about Rainmeter's TransformationMatrix, the implementation is wholly a visible modification; as far as Rainmeter's context is concerned each image still exists at 0,0 at full size. What this means for a mask is although the mask's blitting(? image combination) does a proper mask of the contained image in position, orientation, and scale per matrices, the masked image can also not be moved outside of the image limits of the mask container.

I basically found a hole in the use case. I don't think it's an error now. It's simply out of scope.

It might even be a variation considering I used the container based on the note the the "mask" architecture I found elsewhere in documentation (in the image section) was stated to be deprecated and to use a "container" instead.

[Yincognito]

I basically found a hole in the use case. I don't think it's an error now. It's simply out of scope.

Precisely. Just to illustrate the behavior of a container, I switched the order of the meters in my TransformationMatrix sample skin, made one of the colors "translucent" to better see what happens and added a (commented or not, depending on what's needed) Container option in one of the meters:

Code: Select all

[Variables]
Update=25
Width=200
Height=100
Size=(Sqrt(#Width#**2+#Height#**2))
OffsetX=((#Size#-#Width#)/2)
OffsetY=((#Size#-#Height#)/2)
CenterX=(#Width#/2)
CenterY=(#Height#/2)
Angle=0
AngleIncrement=1
BackgroundColor=47,47,47,96
Color=255,240,0,255

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

---Measures---

[MeasureAngle]
Disabled=1
Measure=Calc
Formula=((MeasureAngle+#AngleIncrement#)%360)
OnUpdateAction=[!SetVariable Angle [MeasureAngle]][!UpdateMeter *][!Redraw]
DynamicVariables=1

---Meters---

; Form: TransformationMatrix={scale x};{skew y};{skew x};{scale y};{move x};{move y}
; Zoom: TransformationMatrix=#Zoom#;0;0;#Zoom#;((1-#Zoom#)*[#CURRENTSECTION#:X]);((1-#Zoom#)*[#CURRENTSECTION#:Y])

[MeterImage]
Meter=Image
SolidColor=#Color#
X=#OffsetX#
Y=#OffsetY#
W=#Width#
H=#Height#
TransformationMatrix=(Cos(Rad(#Angle#)));(-Sin(Rad(#Angle#)));(Sin(Rad(#Angle#)));(Cos(Rad(#Angle#)));((#OffsetX#+#CenterX#)-(#OffsetX#+#CenterX#)*Cos(Rad(#Angle#))-(#OffsetY#+#CenterY#)*Sin(Rad(#Angle#)));((#OffsetY#+#CenterY#)+(#OffsetX#+#CenterX#)*Sin(Rad(#Angle#))-(#OffsetY#+#CenterY#)*Cos(Rad(#Angle#)))
MouseScrollUpAction=[!SetVariable AngleIncrement (Clamp(#AngleIncrement#+1,0,360))]
MouseScrollDownAction=[!SetVariable AngleIncrement (Clamp(#AngleIncrement#-1,0,360))]
LeftMouseUpAction=[!UnpauseMeasure MeasureAngle][!ToggleMeasure MeasureAngle][!UpdateMeasure MeasureAngle][!SetVariable Angle [MeasureAngle]][!SetVariable AngleIncrement 1]
MiddleMouseUpAction=[!TogglePauseMeasure MeasureAngle]
DynamicVariables=1

[BoundingBox]
;Container=MeterImage
Meter=Image
X=0
Y=0
W=#Size#
H=#Size#
SolidColor=#BackgroundColor#
DynamicVariables=1

As you can see, in its original form, the rectangle rotates around its center (left click to start / reset totation, middle click to pause it). Now if you uncomment (i.e. remove the leading ; at the beginning of it) the ;Container=MeterImage line, you'll see that although the solid color "image" in [MeterImage] rotates properly and masks the more or less opaque pixels, the container meter itself doesn't rotate, but stays static. Naturally, what's outside the W and H of the container won't be visible, and because its W and H (and the TransformationMatrix formulas) were set in relation to the #Width# and #Height# variables and not to the required visible "frame" for such a rotation (i.e. Size=(Sqrt(#Width#**2+#Height#**2)) according to the Pythagorean Theorem, see Formulas for this Rainmeter syntax), the rectangle isn't fully visible when rotating the more or less opaque content of the container.

[Mor3bane]

Would anyone mind doing a gif capture of this, please?

I am curious but am wary of the talk about high cpu usages. My system is running high anyway so, the gif would alleviate my curiosities.

[eclectic-tech]

Would anyone mind doing a gif capture of this, please?

I am curious but am wary of the talk about high cpu usages. My system is running high anyway so, the gif would alleviate my curiosities.

Here is a GIF showing the original code action, then adding the 'Container', and refreshing...{Click image to animate}

container1.gif