Number of character or phrase included in a string

[Yincognito]

I guess my overriding point in all of this is that there is no explicit "benefit" in avoiding Lua at all costs. To be honest, I just wouldn't waste a moment of my time saying "Ok, that's easy in Lua, but there must be some way, no matter how complicated, to do the same thing without Lua".

The beauty of Lua, the thing I like about it so much, is that you just need one measure:

Code: Select all

[Lua]
Measure=Script
ScriptFile=MyLua.lua
Disabled=1

And that opens up the entirety of the power of Lua for you in your skins. Then you can write one or a hundred MyFunction() calls in MyLua.lua, and use them anywhere you need them, on demand. They use no resources at all until you "call" one of them, and they can be called, in a specific and reusable way, using Inline Lua, right where and when you need the "answer".

As you alluded to, a [MeasureName] in Rainmeter can only have one "value" at a time. Sure you can !SetOption it and !UpdateMeasure it to change the value, but it still can only have one value at a time. So it makes it a challenge indeed to "reuse" it in multiple places, with dynamic values that adjust to "where" and "when" it is used. Inline Lua entirely solves that issue.

To me, Lua is just a part of Rainmeter, as much as IfCondition or Substitute, or any other option. Using that one measure above, all the libraries and procedural functionality Lua has are in effect added to the toolbelt you have for writing skins.

It's one of the simplest programming languages ever developed, and has a pretty low threshold for entry, even by someone who isn't a programmer.

Now mind you, I'm not going to use Lua when there is a perfectly good alternative in Rainmeter that doesn't require me to include an external .lua file with my skin. All things being equal, I'd just as soon not. But if I can do something easier or more efficiently in Lua, I'm not going to hesitate. Writing Lua code is a lot of fun for me.

Yep, agreed. But since we talk about it, one thing I noticed (and I'm not quite sure about the cause of it) when encountering Lua enhanced skins here on the forum, is the fact that animations done through Lua seem to take a LOT of CPU, compared to what I would envision as their Rainmeter code equivalents. What I wanted to ask someone more familiar with Lua than me is why is this happening? Faulty / inefficient implementations from skin authors, lag due to Lua-Rainmeter interconnectivity, or what? In my experience as a not great, but not bad either programmer, this shouldn't be the case, and if anything, things should be actually more efficient in Lua. Although ... if I think about it, I think it's because Lua does everything through Rainmeter, as you posted somewhere on the forum, and this is what probably leads to such behavior, right?

[jsmorley]

Yep, agreed. But since we talk about it, one thing I noticed (and I'm not quite sure about the cause of it) when encountering Lua enhanced skins here on the forum, is the fact that animations done through Lua seem to take a LOT of CPU, compared to what I would envision as their Rainmeter code equivalents. What I wanted to ask someone more familiar with Lua than me is why is this happening? Faulty / inefficient implementations from skin authors, lag due to Lua-Rainmeter interconnectivity, or what? In my experience as a not great, but not bad either programmer, this shouldn't be the case, and if anything, things should be actually more efficient in Lua. Although ... if I think about it, I think it's because Lua does everything through Rainmeter, as you posted somewhere on the forum, and this is what probably leads to such behavior, right?

The problem with driving animations using Lua is that the connection between Rainmeter and Lua is done in such a way that when the Lua is called, either with a [ScriptMeasure] / UpdateDivider >> Update() approach, or with an [&ScriptMeasure:MyFunction(MyArgument)] Inline Lua approach, control is in effect "handed over" to Lua for the duration of whatever Function() is being executed. Rainmeter is not going to "see" any actions taken by the Lua, any SKIN:Bang() calls that are made, until the entire Function() is complete and control is "returned" to Rainmeter.

It's important to consider that the command "return" in Lua doesn't mean "return some value to the calling program" really, but rather means "return to the calling program with some value". In between the MyFunction() .. return statements, Lua is in the drivers seat. So any "series" of actions that you take in Lua are going to happen "all at once" from the viewpoint of Rainmeter.

It's why there is no Sleep() function built into Lua, even though that is a common and fundamental function in many other languages. Lua is designed from the ground up to be an "embedded", "scripting" tool that is used in conjunction with some other language. Sleep() is just self-defeating in that context.

I don't think this necessarily makes the Lua use more CPU as such, but I just don't think Lua is a good tool for driving animations. I think the best, and really only practical, approach is either a very low Update rate in [Rainmeter] (ick) or using ActionTimer.

[Yincognito]

Thanks for explaining it, it's a bit clearer now.

I think the best, and really only practical, approach is either a very low Update rate in [Rainmeter] (ick) or using ActionTimer.

Not so fast with the "ick", jsmorley. I've done extensive testing on this subject (I admit, the endless animation scenario, not the recommended short and ended one), and Rainmeter with a low Update rate beats ActionTimer in terms of low CPU usage... especially when another software (e.g. Chrome) is using the CPU or GPU too. It is possible that this may be because of the ActionTimer measures' need to update themselves to "see" the dynamic variables (so, an additional operation to the mix), but still, a not so small difference nevertheless on my system (this was tested along other - but the same - skins as well, just to notice the difference better). One other thing, using [!MoveMeter ...] instead of the classic [!UpdateMeter ...][!Redraw] also fares better.

So, in my case, although I was glad to finally managing to make ActionTimer work endlessly (you know, our discussion a while back, it was a matter of adding a Wait interval at the end of a cycle, and that prevented freezing) and thought about switching to it, I reverted back to my previous (and more efficient) low Update rate in the [Rainmeter] section and implemented the [!MoveMeter ...] variant as well. Thankfully, I don't have to worry nowadays about the low update rate flickering my OS tooltips, as everything works great using my custom ones.

[jsmorley]

Thanks for explaining it, it's a bit clearer now.



Not so fast with the "ick", jsmorley. I've done extensive testing on this subject (I admit, the endless animation scenario, not the recommended short and ended one), and Rainmeter with a low Update rate beats ActionTimer in terms of low CPU usage... especially when another software (e.g. Chrome) is using the CPU or GPU too. It is possible that this may be because of the ActionTimer measures' need to update themselves to "see" the dynamic variables (so, an additional operation to the mix), but still, a not so small difference nevertheless on my system (this was tested along other - but the same - skins as well, just to notice the difference better). One other thing, using [!MoveMeter ...] instead of the classic [!UpdateMeter ...][!Redraw] also fares better.

So, in my case, although I was glad to finally managing to make ActionTimer work endlessly (you know, our discussion a while back, it was a matter of adding a Wait interval at the end of a cycle, and that prevented freezing) and thought about switching to it, I reverted back to my previous (and more efficient) low Update rate in the [Rainmeter] section and implemented the [!MoveMeter ...] variant as well. Thankfully, I don't have to worry nowadays about the low update rate flickering my OS tooltips, as everything works great using my custom ones.

The "ick" was really in reference to ANY endless animation in a Rainmeter skin. To each his own, but I hate endless animations on my desktop, and in fact never even use, nor would use, any of the very pretty music "visualizer" skins out there. I'm just not a fan of distractions on my desktop, no matter how well-behaved.

[Yincognito]

The "ick" was really in reference to ANY endless animation in a Rainmeter skin. To each his own, but I hate endless animations on my desktop, and in fact never even use, nor would use, any of the very pretty music "visualizer" skins out there. I'm just not a fan of distractions on my desktop, no matter how well-behaved.

Ah, I see - must have misunderstood things then. To me, these endless animations are needed to display longer strings, as in my case I find much more distracting having the string moving left and then right in ended animations, instead of a continuous and "consistent" / "constant" move in terms of position and velocity. I do agree with you on the visualizer skins, they are really hungry for CPU. I've made mine as efficient as I could, and it still takes 4 times as much CPU as all my other skins combined (which include 3 endlessly animated ones) ... and that is only at the start (as the usage increases over time) and only when idle (the overall Rainmeter CPU usage seems to increase when not idle)! Of course I would personally never use the visualizer skin other than for testing purposes, despite the little bells and whistles, but it was a nice addition to my suite, along with other skins.