Reducing CPU usage?

[ItsJustRyan]

No, you're not, you're right that there are multiple factors (some of which you mentioned now) that influence performance in such a skin, and the effect is cummulative, as you can imagine.

The changes are not extensive, it's more about setting everything to update ONLY when it really needs to. As explained before by others here, big images updated / resized quickly are quite intensive in Rainmeter, so pretty much the only (classic) solution for the vinyl animation (which is the only one in this code you expect to animate smoothly, by the way) is to "decelerate" it via a suited update divider that produces acceptable movement AND performance. I set the related variable to 5 - which means 5 times slower than the skin update rate - and even though the rotation is slower, it's still noticeable and smooth enough if you don't look too closely. Feel free to change it to what you see fit.
[...]
Other than that, in your current / posted skin, properly handling the cover and vinyl rotations does not seem to be enough to improve performance, I set both their update dividers to -1 and even commented them both and I still have 60% CPU usage without HA. The latter helps, of course, but it's only passing the effort to the quicker GPU instead, not actually "fixing" the issue.

I'm currently going back through the code and adding the deceleration and changing some of the UpdateDividers more appropriate for the measures. For me I only set the deceleration to 2, but that's because I have a larger step size for the RotateMeasure and 3 makes it noticeably "jumpy".
I'm about halfway through and the CPU usage (with HA on) reduced from about 8-ish% (I forgot to check what it was but I think it was around 8) to around 4. This may be redundant but just to be safe I added UpdateDivider=-1 to everything that does not need to be updated, even those without DynamicVariables=1. As far as I know, it doesn't hurt besides some more lines of code. One of the things I also did for example, is to stuff like MeasureSongArtist, MeasureShuffle and MeasureRepeat is make it so that it does an OnChangeAction that updates the relevant meters, which now have UpdateDivider=-1 rather than constantly updating. It works, but sometimes there's a noticeable delay, probably due to the lower update rate of the measure.

[Yincognito]

I'm currently going back through the code and adding the deceleration and changing some of the UpdateDividers more appropriate for the measures. For me I only set the deceleration to 2, but that's because I have a larger step size for the RotateMeasure and 3 makes it noticeably "jumpy".
I'm about halfway through and the CPU usage (with HA on) reduced from about 8-ish% (I forgot to check what it was but I think it was around 8) to around 4. This may be redundant but just to be safe I added UpdateDivider=-1 to everything that does not need to be updated, even those without DynamicVariables=1. As far as I know, it doesn't hurt besides some more lines of code. One of the things I also did for example, is to stuff like MeasureSongArtist, MeasureShuffle and MeasureRepeat is make it so that it does an OnChangeAction that updates the relevant meters, which now have UpdateDivider=-1 rather than constantly updating. It works, but sometimes there's a noticeable delay, probably due to the lower update rate of the measure.

Yeah, that's it, if you got a drop from 8% to 4%, it's clear you're on the right path - well done.

As for the rest, to be even more precise on this, the update of sections itself rarely impacts performance significantly (unless you have lots a lots of complex math going on), what really does it is the skin redraw process (which paints it on the screen). Of course, updating something without it being reflected visually makes little sense, so that's why the two are often connected.

Good idea with the OnChangeAction system in those cases. The delay might be because you didn't add [!Redraw] after you update the relevant meters in those options - this ensures the skin is redrawn immediately after the change happens. Simply updating the meter doesn't reflect anything visually, thus a redraw is needed for that. What I don't know is whether Rainmeter has an optimization system to "merge" multiple redraws that come from different places at the same time into a single one, otherwise you might end up redrawing multiple times in a tiny amount of time and effectively make things worse in that tiny amount of time (albeit better overall, for the rest of the time).

Anyway, there is progress, and that's good news! Keep it going, squeeze the usage as much as you can, or at least until you think it's reasonable. The way it was in the beginning was just too bad in terms of performance, that's the truth.

[ItsJustRyan]

Got it down to about 3ish%, but I think that's as low as it goes without also messing with the AudioLevel Visualizer stuff as well. Went a bit ham on the OnChangeActions and made everything use an updateDivider=-1 where I could.

Ultimately I didn't decelerate the vinyl spinning, but added a variable so that it can be changed easily. I was thinking about doing the updateDivider=-1 for the audioLevel meters (there's about 40 of them), but wasn't sure if it would be worth it as the measures would still constantly update anyways. Also took the opportunity to iron out some issues like the text marquee acting weird and such.

For some reason though, when I make a copy of the skin to upload (to erase the contents of the text files and such) some of the things seem to break, like file/folder view. Last time I thought it was because I had gone through the code as well and removed some things like shortcuts to apps and other skins I have and erased something I shouldn't have, but this time I didn't touch it so I'm not too sure what's happening there.

Still nice that the most CPU intensive thing in this skin is now the Python code it runs (which for some reason takes up almost 10% each time). I tried using C++ but couldn't figure out how to link the OpenCV libraries after 2 hours so that's for another day.

TurnTable II_.rmskin

[Yincognito]

Got it down to about 3ish%...

That sounds nice, but on my AMD Ryzen 5 5600H CPU with AMD Radeon RX Vega 6 (integrated) & NVIDIA GeForce GTX 1650 (discrete) GPUs, it still goes into 12% with HA and 70% without, after setting the player from your AIMP to my Winamp to animate things, as my skin suite above shows:

Trntable II - Preview - HA On.jpg

Trntable II - Preview - HA Off.jpg

Maybe others (ActiveColors, eclectic-tech) fare better?

[ItsJustRyan]

That sounds nice, but on my AMD Ryzen 5 5600H CPU with AMD Radeon RX Vega 6 (integrated) & NVIDIA GeForce GTX 1650 (discrete) GPUs, it still goes into 12% with HA and 70% without...

I know what you said about meters earlier, but is it possible that the 30ish AudioLevel Meters with UpdateDivider=1 is the cause? Even though I did DisableMeasureGroup for the measures, the meters are not disabled, only hidden from view at times. Assuming I did the DisableMeasureGroup bang correctly and it actually works, which it seems to from testing but can never be sure. Is it also practical to go through and also do the OnUpdateChange for each individual measure and corresponding meter, or should I just put all the meters into one group and disable/enable whenever they are hidden/unhidden and let them remain UpdateDivider=1. And would doing so also introduce a delay to the meter? I noticed with the one that measures audio level of the input microphone that it appears to be slightly delayed, although that could also be due to other factors.

Code: Select all

[MeasureMicAudio]
Measure=Plugin
Plugin=AudioLevel
Port=Input
RMSAttack=50
RMSDecay=300
RMSGain=6
UpdateDivider=1
Group=AudioMeasures

[MeasureMic]
Measure=Plugin
Plugin=AudioLevel
Parent=MeasureMicAudio
Type=RMS
UpdateDivider=1
Group=AudioMeasures
OnChangeAction=[!UpdateMeter VisAppmeterBarMic][!UpdateMeter VisAppmeterMic]

[VisAppmeterMic]
Meter=String
MeasureName=MeasureMic
AntiAlias=1
FontColor=255,255,255,220
FontSize=7
FontWeight=700
X=(950+#iPadX#)
Y=(478-#iPadY#)
W=522
H=14
Text=%1
StringAlign=CenterCenter
NumOfDecimals=2
Hidden=1
UpdateDivider=-1
Container=IpadScreen
Group=ipadgroupApps | ipadVisApp

[VisAppmeterBarMic]
Meter=Bar
MeasureName=MeasureMic
X=(969+#iPadX#)
Y=(477-#iPadY#)
W=480
H=2
BarOrientation=HORIZONTAL
BarColor=255,156,0
SolidColor=255,255,255
Hidden=1
UpdateDivider=-1
Container=IpadScreen
Group=ipadgroupApps | ipadVisApp

[Yincognito]

I know what you said about meters earlier, but is it possible that the 30ish AudioLevel Meters with UpdateDivider=1 is the cause? Even though I did DisableMeasureGroup for the measures, the meters are not disabled, only hidden from view at times. Assuming I did the DisableMeasureGroup bang correctly and it actually works, which it seems to from testing but can never be sure. Is it also practical to go through and also do the OnUpdateChange for each individual measure and corresponding meter, or should I just put all the meters into one group and disable/enable whenever they are hidden/unhidden and let them remain UpdateDivider=1. And would doing so also introduce a delay to the meter? I noticed with the one that measures audio level of the input microphone that it appears to be slightly delayed, although that could also be due to other factors.

Although AudioLevel measures are known to be a bit intensive due to what they do, they can't be the cause of such a significant usage - it's the big image animation, and like I said before, it happens in my example earlier as well, if I set the deceleration to 1 (i.e. no deceleration, everything updating once every 20 ms). Regarding the group, I also have such groups in my skin suite, and I both hide/show AND disable/enable the entire groups as desired (for the record, my "visualizer" is updated twice as slow as the rest of my animated skin, at 50 ms, to drop the usage with another 2% or so, and even though it's not realtime I'm ok with the effect and performance). As for your code above, I still don't see the [!Redraw] after updating meters in [MeasureMic], and this might be very well the cause of the occasional delay. By the way, if you're unsure about some section of your code, put it temporarily in a test skin alone to figure out the problem and the solution if any, since working with a large skin makes a bit difficult to precisely identify these things.

[ItsJustRyan]

As for your code above, I still don't see the [!Redraw] after updating meters in [MeasureMic], and this might be very well the cause of the occasional delay.

I did have !Redraw on there initially, but when it didn't seem to make a difference (at least from what I could tell) I removed it. I think it might just be because of the presence of the redraw, because I noticed when I had it the other animations visibly slowed.

Also was wondering, how does rainmeter handle things like decimal points in stuff like updateDivider? There would be places where I wanted it to update very say 200ms so I do (200/#UpdateValue#), but if the updateValue is something like 16, would it do the calculation and then round it, or does it work by being a threshold of sorts and each update it adds to a counter until it surpasses the threshold and updates?

[Yincognito]

Also was wondering, how does rainmeter handle things like decimal points in stuff like updateDivider? There would be places where I wanted it to update very say 200ms so I do (200/#UpdateValue#), but if the updateValue is something like 16, would it do the calculation and then round it, or does it work by being a threshold of sorts and each update it adds to a counter until it surpasses the threshold and updates?

As far as I know (hopefully, I'm not mistaken), it doesn't round it, it truncates it. Meaning, it will use the integer part of the calculation (e.g. 3.56 will be 3). It certainly doesn't use a threshold.