RicardoTM wrote: ↑February 20th, 2024, 5:52 am
Sure, they still need some polish and I'll make sure they look the best when fully implemented. These are just for you so you can deliver your gift
![Smiler :)](./images/smilies/ab.gif)
. Since that update won't be released soon.
Although this might depend on everyone's cpus, I tested with 6 gauges and it didn't go above 1%. I run an old i7 6700, it stayed drifting between 0 and 0.5% (when running only the gauges with no other skin active, an update rate of 5 seconds, and not being manipulated). It can go up when hovering with the mouse but couldn't find a way to avoid it, it seems like inline effects (the text's "glow") are quite cpu heavy.
The workaround would be to add a way to disable these things for users with lower end hardware.
Yes, inline shadow is indeed CPU intensive, especially if used in multiple inline settings at the same time, like needed to simulate the glow effect. The skin size on screen is also relevant here, since larger skins / meters (possibly using larger images / shapes, or images scaled up via altering their original W and H) use more CPU when drawn. Also, like I said elsewhere, the effect is cumulative, so if you have other "CPU intensive" skins loaded at the same time (like it's usually the case, e.g. either other gauges or, like me, the animated skins from my suite loaded as well, for a similar 4% total CPU usage on my Ryzen 5600H), then resource consumption will increase overall. Using dynamic variables (including nested ones, which are by default dynamic) slightly add to this too.
Generally, using either static or dynamic update dividers to make skins lighter on the CPU does help (and sometimes massively), but in the end, the main consumer of resources in skins is the workload and the frequency involved in redrawing skins, and this depends on the type, size and amount of visual elements in the skin as well as the [Rainmeter]'s Update value (the latter being non-dynamic and representing how often the skin is updated and redrawn, regardless of any update dividers elsewhere in the skin, by the way). One can place a part of the workload from the CPU on the (preferably, dedicated) GPU via using Hardware Acceleration, of course, but the workload will be the same, just distributed more efficiently.
Anyway, even 4% total CPU usage is a perfectly reasonable resource consumption for Rainmeter using this type of skins (and possibly others alongside them), so I wouldn't worry too much about it. No visually dynamic benefit comes for free, regardless of software, and there are many factors (some either unavoidable or non negotiable, so to speak) influencing this.