It is currently March 29th, 2024, 12:42 am

Help in programming

Get help with creating, editing & fixing problems with skins
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Help in programming

Post by jsmorley »

I will say that I am very leery of setting Update to anything other than 1000 (once a second).

I understand that there are some skins, mostly AutoLevel plugin skins, that might require a faster update rate in order to be responsive and smooth. My advice there is to limit their use, only have them running when you need them, and try hard to limit what that particular skin does to just the measures and meters you need for the AudioLevel stuff.

What I mean by that is that if you have Update=25 and DefaultUpdateDivider=40, then the overall skin will update every 25 milliseconds, and any and all measures and meters that don't have any UpdateDivider on them will update once a second. (25*40=1000) So you just set UpdateDivider=1 on the AudioLevel measures and meters, so they update every 25 milliseconds, but have any other measures or meters, not related to the AudioLevel stuff, update once a second.

That sounds good, and in some cases is the right way to go to fine-tune things, but I caution... Even though all those "other" measures and meters are updating at the slower rate, and that is very good for CPU usage, you have to keep in mind that the skin in general is still updating every 25 milliseconds. That means that Rainmeter will cause Windows to "redraw" the skin on the screen every 25 milliseconds. In addition, there are some things, like resizing an image with W and H on a meter, that happen during this "redraw" portion of the cycle, and not in the "update" portion of the individual meter(s).

Resizing images with W and H is probably the single most "expensive" thing you can do in Rainmeter. It is a lot of "work" in a relative sense, particularly resizing a "large" image to a "small" size, and will always happen on every single update of the skin.

So the long and the short of it is that any skin set with Update=25 is going to be relatively "expensive" on CPU and GPU. The goal is to do as LITTLE as possible in this skin, and move all the other cool stuff you want to do to other less expensive skins that are set to Update=1000. Have skins that use AudioLevel and display a "visualizer" be a skin dedicated to only that. Don't create huge skins that measure all kinds of things and also have a music visualizer in them. That is a recipe for high CPU/GPU usage.
User avatar
balala
Rainmeter Sage
Posts: 16110
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Help in programming

Post by balala »

jsmorley wrote: November 10th, 2019, 3:19 pm I will say that I am very leery of setting Update to anything other than 1000 (once a second).
I completely agree, but just mentioning that there are some cases when Update=-1 is a better choice. For instance the mouse controlled skins (like launchers for example), this is a better possibility. Obviously what is better depends on a lot of things...
User avatar
sl23
Posts: 1140
Joined: February 17th, 2011, 7:45 pm
Location: a Galaxy S7 far far away

Re: Help in programming

Post by sl23 »

Thanks for those tips. I've disabled Launcher updates. Is that enough to reduce CPU usage?
- MuLab -
User avatar
balala
Rainmeter Sage
Posts: 16110
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Help in programming

Post by balala »

sl23 wrote: November 10th, 2019, 8:26 pm Thanks for those tips. I've disabled Launcher updates. Is that enough to reduce CPU usage?
What do you mean by "Launcher updates"? As jsmorley wrote to reduce the CPU usage, you should dissect the skin into two distinct skins: one with the AudioLevel plugin measures and the appropriate meters (with a low Update value) and the other with all other sections, with the default Update=1000.
User avatar
sl23
Posts: 1140
Joined: February 17th, 2011, 7:45 pm
Location: a Galaxy S7 far far away

Re: Help in programming

Post by sl23 »

But I don't want to! :p

Win10 Task Manager Shows Rainmeter uses:
CPU = 0.9% (max) avg seems to be 0.7%
RAM = 19.7MB

Is that a lot? I only have 3 skins, but a great many measures and meters are in them.

When a measure or meter is disabled using a bang or command of some sort, does it reduce the system usage at all?
- MuLab -
User avatar
balala
Rainmeter Sage
Posts: 16110
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Help in programming

Post by balala »

sl23 wrote: November 10th, 2019, 9:46 pm Win10 Task Manager Shows Rainmeter uses:
CPU = 0.9% (max) avg seems to be 0.7%
RAM = 19.7MB

Is that a lot? I only have 3 skins, but a great many measures and meters are in them.
jsmorley has described you why and how could you reduce the CPU usage. Maybe it's not too much, but everything counts (in my opinion).
sl23 wrote: November 10th, 2019, 9:46 pm When a measure or meter is disabled using a bang or command of some sort, does it reduce the system usage at all?
Meters are not disabled, the are hidden (or shown). Measure can be disabled. Although hiding a meter / disabling a measure can reduce the CPU usage, as I also said above, jsmorely has described how a skin with even disabled measures / hidden meters can affect the CPU usage.
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Help in programming

Post by jsmorley »

There is really never any need to "disable" a meter. You actually can't technically do that anyway, but you can in effect, by using UpdateDivider on it. Don't bother. The amount of work that is done to update a meter really rounds to zero. The work is all done by the measures deriving the value for the meter, and the skin when it is "redrawn" on the screen. Carefully control the measures, carefully control the skin. The meters generally don't matter. You can be a perfectionist and put UpdateDivider=-1 on a "static" meter like a background, and that's fine, I'm not arguing "against" it, but don't expect that to save you anything appreciable.

That is why I caution that skins that have a lot of measures that are updating at a very rapid pace, and skins that are complicated to "draw" on the screen, need to be designed carefully. Any skin with an update lower than 100 just won't exist on my system. It's why I won't use a music visualizer. It's so hard to make the CPU / GPU usage worth the visual gain of the skin, that I just won't be bothered with it. I "hear" music. I don't really need to "see" it. Get off my lawn...

I'm fine with animations that need to run rapidly, that is what ActionTimer is for. But note that the use and intent of ActionTimer is to have this ramped-up effort be in short bursts, and not continuously. If I need to use some CPU for a second, while my skin slides over, or my menu opens, or a mole pops his head out of a hole, that's fine. ActionTimer allows you to "beat" the normal Update of 1000, but only when and while you really need it. A skin with Update=16 is just too much overhead. I will always avoid it.

To each his own mind you. I know music visualizers are quite popular. Just be aware and take the time to think through the design of the skin in question and what else the skin really needs to do.
User avatar
sl23
Posts: 1140
Joined: February 17th, 2011, 7:45 pm
Location: a Galaxy S7 far far away

Re: Help in programming

Post by sl23 »

Thanks for the information. :thumbup:

As it stands, I'm not concerned by the current usage, It was just out of curiosity, to know if that was a high usage or not.

Launchers are app launchers btw, which all now have the UpdateDivider=-1 so it should have minimal impact.

I don't wish to draw this conversation out and take up your valuable time. As I said it's of no concern, just querying it that's all.

Thanks again :great:
- MuLab -