Hey there!
I've seen a great performance loss after using a custom cursors in meters. ~20 meters with custom cursor (the same) causes work skin so slowly.
I will speak about 1 cursor file (83kb, *.ani).
The way how to add it is no important: as variable or full name - result is same. All meters have DynamicVariables is on.
How do Rainmeter works with custom cursors? It loads in every update cycle? I have no ideas why using it forces performance to go down in geometrical progression with each another meter with this option, even when it's not really used (mouse is not over the meters).
Maybe i just do something wrong?..
It is currently March 28th, 2024, 11:35 pm
[Performance] Custom Cursors
-
- Posts: 209
- Joined: July 12th, 2020, 7:47 am
- Location: Ada, Garden City
-
- Rainmeter Sage
- Posts: 7029
- Joined: February 27th, 2015, 2:38 pm
- Location: Terra Yincognita
Re: [Performance] Custom Cursors
It shouldn't be the case. I didn't use external custom cursors yet in Rainmeter, but maybe you can post the cursor file so other folks can see if they can replicate the issue. Unless it's a crazily animated cursor, I don't see any reason for performance loss. Even if it was, I would first make sure that the problem lies in the cursor thing and not in the code itself.deflore08 wrote: ↑August 5th, 2020, 1:59 am Hey there!
I've seen a great performance loss after using a custom cursors in meters. ~20 meters with custom cursor (the same) causes work skin so slowly.
I will speak about 1 cursor file (83kb, *.ani).
The way how to add it is no important: as variable or full name - result is same. All meters have DynamicVariables is on.
How do Rainmeter works with custom cursors? It loads in every update cycle? I have no ideas why using it forces performance to go down in geometrical progression with each another meter with this option, even when it's not really used (mouse is not over the meters).
Maybe i just do something wrong?..
-
- Rainmeter Sage
- Posts: 16110
- Joined: October 11th, 2010, 6:27 pm
- Location: Gheorgheni, Romania
Re: [Performance] Custom Cursors
There is not needed to set dynamic variables on meters having set custom cursors, with the MouseActionCursorName option.
Otherwise I agree with Yincognito to post the cursor and additionally the involved code as well:
Help us please to can help you.Yincognito wrote: ↑August 5th, 2020, 5:45 pm but maybe you can post the cursor file so other folks can see if they can replicate the issue.
-
- Posts: 209
- Joined: July 12th, 2020, 7:47 am
- Location: Ada, Garden City
Re: [Performance] Custom Cursors
Hello again!
Yes, my bad, i quess i really should lead some code and files.
So.. Cursors in attachment. I am not sure which code part i must lead here. It works with next approach:
I have .ini skin as entry point. The skin includes some modules (25+) through @include. Some meters in these modules have an option MouseActionCursorName = #Cursor_Slider_X#. There is some variables which determines cursors path like Cursor_Slider_X = "SizeWE.ani".
Meters has DynamicVariables = 1 not because of cursors, it's about Y = (#Pad# + 123), so i cannot reject it. Just i thought it may have any sense for explanation.
When i reject to use custom cursors, for example i just comment variables with ;, skin works in turbo-mode. When i adding cursors in meters, it slows proggressively with each new meter, which uses cursor file (approach like direct path or througth a variable is not important). Actually it does not care that cursor is really using now, or skin just in "rest". It is not about physical cursor files, but about amount of meters which uses a cursor (it might be just 1 file).
Well.. I don't know how to explain it better now. I can show an example. Sure, skin that contains this code part is included to main skin with @include option.
Aaaand.. If i have 5-10 meters with cursor - it's not "OK" but "ok". When i got 20 - it makes skin a turtle. With 50 meters it is..
Thanks for attention folks.
Yes, my bad, i quess i really should lead some code and files.
So.. Cursors in attachment. I am not sure which code part i must lead here. It works with next approach:
I have .ini skin as entry point. The skin includes some modules (25+) through @include. Some meters in these modules have an option MouseActionCursorName = #Cursor_Slider_X#. There is some variables which determines cursors path like Cursor_Slider_X = "SizeWE.ani".
Meters has DynamicVariables = 1 not because of cursors, it's about Y = (#Pad# + 123), so i cannot reject it. Just i thought it may have any sense for explanation.
When i reject to use custom cursors, for example i just comment variables with ;, skin works in turbo-mode. When i adding cursors in meters, it slows proggressively with each new meter, which uses cursor file (approach like direct path or througth a variable is not important). Actually it does not care that cursor is really using now, or skin just in "rest". It is not about physical cursor files, but about amount of meters which uses a cursor (it might be just 1 file).
Well.. I don't know how to explain it better now. I can show an example. Sure, skin that contains this code part is included to main skin with @include option.
Code: Select all
Cursor_Slider_Y = "SizeNS.ani"
Cursor_Slider_X = "SizeWE.ani"
[text.Main_Settings_SYSTEM_VOLUME_STEP_Value]
Meter = String
MeterStyle = style.text.Simple_Font_Right_Align
FontColor = #Font_Value_Color#
X = 950
Y = (#Pad_Top# + 137)
W = 20
Text = "#Sys_Volume_Step#"
DynamicVariables = 1
Hidden = #Settings_Main#
MouseActionCursorName = #Cursor_Slider_Y#
MouseScrollUpAction = [!SetVariable Sys_Volume_Step "(#Sys_Volume_Step# + 1)"][!WriteKeyValue Variables Sys_Volume_Step "(#Sys_Volume_Step# + 1)" "#@#\Settings.ini"]
MouseScrollDownAction = [!SetVariable Sys_Volume_Step "(#Sys_Volume_Step# - 1)"][!WriteKeyValue Variables Sys_Volume_Step "(#Sys_Volume_Step# - 1)" "#@#\Settings.ini"]
Thanks for attention folks.
You do not have the required permissions to view the files attached to this post.
-
- Rainmeter Sage
- Posts: 16110
- Joined: October 11th, 2010, 6:27 pm
- Location: Gheorgheni, Romania
Re: [Performance] Custom Cursors
You should add the whole code, not just one meter, to let us to follow what's going on with all those meters. Using the only one posted meter doesn't cause any trouble for me, but if there are so many meters as you said, maybe it's not impossible.
My first advice (but definitely not related to the issue) is to remove all those completely useless spaces in the posted options. For instance instead of the posted X = 950 option, recommend X=950.
Secondly, quotes are not needed around the options (instead of Text="#Sys_Volume_Step#" use Text=#Sys_Volume_Step#).
Thirdly, as asked, post the whole code please.
As said, the first two recommendations definitely won't fix the issue.
-
- Posts: 209
- Joined: July 12th, 2020, 7:47 am
- Location: Ada, Garden City
Re: [Performance] Custom Cursors
I am not sure what code i should post. There is 12k sloc and only some meters uses cursors. I posted all what touches "cursor mechanic". I mean, there is no measures with conditions or something else what controls this "mechanic". Just options (MouseActionCursorName) which use a variable with a path. But even direct approach without variables (MouseActionCursorName="SizeWE.ani") causes skin to work slower. Useless spaces is just for my comfort in works with IDE, really i don't think it's a trouble in this case.balala wrote: ↑August 5th, 2020, 7:54 pm You should add the whole code, not just one meter, to let us to follow what's going on with all those meters. Using the only one posted meter doesn't cause any trouble for me, but if there are so many meters as you said, maybe it's not impossible.
My first advice (but definitely not related to the issue) is to remove all those completely useless spaces in the posted options. For instance instead of the posted X = 950 option, recommend X=950.
Secondly, quotes are not needed around the options (instead of Text="#Sys_Volume_Step#" use Text=#Sys_Volume_Step#).
Thirdly, as asked, post the whole code please.
As said, the first two recommendations definitely won't fix the issue.
-
- Rainmeter Sage
- Posts: 16110
- Joined: October 11th, 2010, 6:27 pm
- Location: Gheorgheni, Romania
Re: [Performance] Custom Cursors
No, it definitely isn't:
(see the parentheses).
The whole code. Just to can follow exactly what's going on there, when the skin is loaded. Even if it is quite large.
-
- Posts: 209
- Joined: July 12th, 2020, 7:47 am
- Location: Ada, Garden City
Re: [Performance] Custom Cursors
Whole code is here. Entry point is AuroraBar\Bar\AuroraBar.ini.
But do you really want to see it whole? Actually i think it's only about cursor things, exclude other mechanics. But sure, it's my own opinion, based on some tests in aurora. I got to test it with "clear" skin with lot of cursored meters, but have no time for this right now. I've asked it here because maybe anyone knows something about this and can tell it.
For example meters with cursors you may find here at 450 line and below. Variables stores in useless Cursor.ini file. Yep, for now it's .ini (not *.inc - it's about IDE and syntax highlight, while i work on this).
But do you really want to see it whole? Actually i think it's only about cursor things, exclude other mechanics. But sure, it's my own opinion, based on some tests in aurora. I got to test it with "clear" skin with lot of cursored meters, but have no time for this right now. I've asked it here because maybe anyone knows something about this and can tell it.
For example meters with cursors you may find here at 450 line and below. Variables stores in useless Cursor.ini file. Yep, for now it's .ini (not *.inc - it's about IDE and syntax highlight, while i work on this).
-
- Rainmeter Sage
- Posts: 7029
- Joined: February 27th, 2015, 2:38 pm
- Location: Terra Yincognita
Re: [Performance] Custom Cursors
Wow, that's really nice what you did there.deflore08 wrote: ↑August 5th, 2020, 9:01 pm Whole code is here. Entry point is AuroraBar\Bar\AuroraBar.ini.
But do you really want to see it whole? Actually i think it's only about cursor things, exclude other mechanics. But sure, it's my own opinion, based on some tests in aurora. I got to test it with "clear" skin with lot of cursored meters, but have no time for this right now. I've asked it here because maybe anyone knows something about this and can tell it.
For example meters with cursors you may find here at 450 line and below. Variables stores in useless Cursor.ini file. Yep, for now it's .ini (not *.inc - it's about IDE and syntax highlight, while i work on this).
I didn't look into the code much yet, but what I can say for sure is that the skin is a turtle right from the start, taking 25%+ of my CPU, so my initial assessment was that the culprit was not the cursors. To test whether I was right or not I replaced MouseActionCursorName with ;MouseActionCursorName in all the files where the former string was found (effectively disabling whatever cursors were used in the skin), and just as expected... it was still a turtle. However, considering that Rainmeter automatically loads the cursors from the appropriate path, I eliminated this possibility as well, by renaming the cursors folder to notcursors (effectively preventing Rainmeter from loading anything from there) and the high CPU usage persisted.
So, the conclusion is: it's NOT the cursors, period. I wished that they were the culprit though, as now we're back at square one, trying to figure out what's taking so much CPU. The skin complexity doesn't help in this endeavour, and neither does the fact that there are lots of possible culprits in the code, from transformation matrices to sounds and whatnot, so that's a task for tomorrow. What you can do though is temporarily comment the includes in your main .INI file one by one, in order to see which one of them contains the CPU hog. Then, you could apply a similar "search & destroy" tactic to narrow down the possibility in the included file you identified previously as well. Eventually, from large scale to small scale, you'll be able to find out what is / are the culprit(s) and see what can be done about it or further ask for help here. It helps here that your code has a well defined structure and order, so that could make the task of progressively comment out sections of the code to find the problem's location easier...
-
- Posts: 209
- Joined: July 12th, 2020, 7:47 am
- Location: Ada, Garden City
Re: [Performance] Custom Cursors
Haha, thanks! Yes, it's turtle right from start (but still enough fast to work without delays on my laptop), because there is too low update rate. Usually it eats 9-12% of my CPU if ActionTimer things are inactive (checked while maaany months..), up to 15-25% in a moments, when some ActionTimer enabled. But it could be lowered to 3-4% by lowering update rate to, let's say, 300ms. Or even to 1-2% if you set 1000-2000ms. (Usually i set 20-100ms, depends on my mood).
So, i tried way that you suggest with commenting and setting modules off. This way lead me to cursors yesterday (and one more thing that i fixed..it was forced changing update dividers for histograms in some places) When i speak about "skin works slowly", i speak not about CPU load. Adding cursors does not cause load's growth. It is all about delays in skin.
For example, when your mouse is over triangles at edges or in any part of main bar, it runs actiontimer plugin what begins some fade-animations. And if will add cursors in meters, delays between moments when rainmeter catch mouse state and do something, and when you move mouse to element will grow up. I don't think that is about action timer and something else, because i tested it even in simple place where mouseover action does nothing. As example - "TOTAL THREADS" or "UNCORE CLOCK" in mid (before i add fade effect on main bar). Left click to them will extend skin a bit, but they have not "MouseOverAction" option, only LeftMouseUpAction, so if you place mouse there it changes nothing. But Rainmeter begins to catch it with big delay, if i use customs cursors in OTHER places, not on these 2 meters (as example). And CPU load does not changes, it is always in one range, with or without cursors. But skin changes behaviour depends on this, in bad side..
Well.. I have so much work at the moment, so now i will leave this problem till 8-9 august.. Maybe i really should look to Actiontimers side or something else.. And yes, thank you.
So, i tried way that you suggest with commenting and setting modules off. This way lead me to cursors yesterday (and one more thing that i fixed..it was forced changing update dividers for histograms in some places) When i speak about "skin works slowly", i speak not about CPU load. Adding cursors does not cause load's growth. It is all about delays in skin.
For example, when your mouse is over triangles at edges or in any part of main bar, it runs actiontimer plugin what begins some fade-animations. And if will add cursors in meters, delays between moments when rainmeter catch mouse state and do something, and when you move mouse to element will grow up. I don't think that is about action timer and something else, because i tested it even in simple place where mouseover action does nothing. As example - "TOTAL THREADS" or "UNCORE CLOCK" in mid (before i add fade effect on main bar). Left click to them will extend skin a bit, but they have not "MouseOverAction" option, only LeftMouseUpAction, so if you place mouse there it changes nothing. But Rainmeter begins to catch it with big delay, if i use customs cursors in OTHER places, not on these 2 meters (as example). And CPU load does not changes, it is always in one range, with or without cursors. But skin changes behaviour depends on this, in bad side..
Well.. I have so much work at the moment, so now i will leave this problem till 8-9 august.. Maybe i really should look to Actiontimers side or something else.. And yes, thank you.