Hey the update is ready, Light theme is not implemented yet but here are white versions of the gauges for you. Just replace the originals with these (you may want to backup the originals). Of course you will have to edit the other colors yourself.
Cheers, everything's perfect now. Especially with the new font outlines that are highly visible on both white and black gauges.RicardoTM wrote: ↑February 20th, 2024, 12:36 am Hey the update is ready, Light theme is not implemented yet but here are white versions of the gauges for you. Just replace the originals with these (you may want to backup the originals). Of course you will have to edit the other colors yourself.
Light.rar
Originals are at @Resources/Images/Themes
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 giftSozo wrote: ↑February 20th, 2024, 5:17 am Cheers, everything's perfect now. Especially with the new font outlines that are highly visible on both white and black gauges.
The CPU usage is well under 4%, which is 5 times less CPU usage than before the update, not to mention I also made the refresh rate 2 seconds.
The white gauges look pretty good too, though the "Tough" white version needs a bit more contrast between its foreground and background, and the "Digital" white version foreground is slightly brighter than its background, so it's not completely seamless-looking like the black version, but these are very small issues I can fix. Other than that, I think the white gauges are good to be released in the future.
Again, thanks for all your help.
. Since that update won't be released soon.
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.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
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.
Yup, I tried deactivating dynamic variables for all the text meters (and activating them only when necessary) but there was no real benefit, it was actually more complicated when communicating with the settings and hsliders skin. So I only did it on mesures and the image meters, these only use dynamic variables when the state measured value changes, and when the design is changed. Only deactivating inline shadows completely would help (only when on hover) but was not worth it, I like those effects lol.Yincognito wrote: ↑February 20th, 2024, 10:14 am 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.
The CPU usage benefit in not using dynamic variables exists, it's just that it's typically so small that it can't be noticed for "normal" skins - but yeah, it's definitely inconvenient without dynamic variables for some things. The scaling down process itself is also probably harder to notice in terms of CPU usage, or maybe it's balanced / canceled by the fact that skins use less CPU to draw fewer pixels then, though the image / meter size will still count regardless of scaling it or not (obviously by far not as much as when scaling is involved). The effect of HA can be seen for really intensive stuff, and depends on some factors that will at times produce less significant results than expected.RicardoTM wrote: ↑February 20th, 2024, 9:33 pm Yup, I tried deactivating dynamic variables for all the text meters (and activating them only when necessary) but there was no real benefit, it was actually more complicated when communicating with the settings and hsliders skin. So I only did it on mesures and the image meters, these only use dynamic variables when the state measured value changes, and when the design is changed. Only deactivating inline shadows completely would help (only when on hover) but was not worth it, I like those effects lol.
By the way, you said images only when scaled up, in this case the images are only scaled down. So I guess no problem there.
Mmm, not sure if I have hardware acceleration on. I'll check that, didn't test with it, didn't even remember that option existed lol.
In this case Hardware Acceleration does help. Especially when the lists are open.Yincognito wrote: ↑February 20th, 2024, 10:07 pm The CPU usage benefit in not using dynamic variables exists, it's just that it's typically so small that it can't be noticed for "normal" skins - but yeah, it's definitely inconvenient without dynamic variables for some things. The scaling down process itself is also probably harder to notice in terms of CPU usage, or maybe it's balanced / canceled by the fact that skins use less CPU to draw fewer pixels then, though the image / meter size will still count regardless of scaling it or not (obviously by far not as much as when scaling is involved). The effect of HA can be seen for really intensive stuff, and depends on some factors that will at times produce less significant results than expected.
Excellent! The only two minor issues with HA are these:
Light Mode is now implemented. This is a really important update because the file restructure is now complete. This is practically the most stable version of all. Future updates won't delete user created gauges and their variables anymore. Raincolors.lua has been implemented.
