I thought gathering all known Rainmeter optimizing do's and dont's, or a "Skin Optimizing 101" if you will, in one thread would be a great idea. These are just some tricks that come to mind at the moment. Feel free to post any suggestions or tricks of your own. Also, don't hesitate to correct me if you think I'm wrong.
Best regards,
Omardude
Optimizing Rainmeter
Faster startup of Rainmeter (Cleaning up the Rainmeter.ini file):
Clean up your Rainmeter.ini file! If you test a lot of different configs on a regular basis, this file is most likely huge. By removing skin settings for skins you're not planning to use anymore Rainmeter doesn't have to plunge through loads of unused code every time it starts up. Click here for more info! (Thanks to sgtevmckay)
Faster shutdown of Rainmeter (Less active skins):
As Rainmeter terminates one skin at a time when you're shutting down Rainmeter, having a lot of active skins will slow this down. My solution to this is using one .ini file that uses @Include to include all my skins (which are all changed to .inc files). This of course makes it impossible to drag skins around separately and requires you to change nearly all positioning values unless you're mostly using relative positioning. I.e. this is not for everyone.
Optimizing Measures
Decreasing CPU usage with UpdateDivider:
By default the Update value is 1000ms (1 sec). Now, if you're skin measures say; RAM, free disk space, etc.. Be sure to add an UpdateDivider to these measures! E.g. you don't need Rainmeter to check how much free space you have left every second! So to those measures you don't need constantly updated, add an UpdateDivider value.
Less measures = Better performance:
Find ways to use less measures if possible. Example: Click here. (Thanks to GhostMatrix)
Optimizing Meters
Decreasing RAM usage with less/smaller images:
Skins that use images are likely to be your most RAM demanding. So, if you're planning on making say, a launcher dock with some fancy border, have this in mind.
E.g.: If you're creating a "task bar" like launcher dock with a height of 150 and you have a cool border you want to use; that border image doesn't have to be 150 pixels high! Most likely, the lower part of the image has only one color or a simple gradient. So by cutting down the height of the image and combining the border image with a simple image meter you've saved some precious RAM.
Use MeterStyles:
Using MeterStyles is a great way to slim down your code! It pretty much does the same as variables, but requires less coding for each meter.
The following is extracted from the User Manual for further explanation:
This allows you to create CSS-like "Styles" for meters. The current meter will use the settings from the specified style as its own. A "Style" is really just another section, however it is not necessarily a meter or measure. Any settings within the style that apply to the meter using it will automatically be used as though they were written within the meter itself.
Example:
[MyStringStyle]
FontColor=#FontColor#
FontFace=TheSansBold-Caps
FontSize=11
StringEffect=SHADOW
StringStyle=BOLD
StringAlign=LEFT
AntiAlias=1
;Then in any meter, use:
[Meter]
Meter=STRING ;(or any other meter type)
MeterStyle=MyStringStyle
The settings for [Meter] are "inherited" from MeterStyle. In the example, the string would have TheSansBold-Caps as the font and the text would be size 11, shadowed, bold, antialiased and aligned to the left. Note that any settings that already exist in the meter take precedence and will override the ones found in the style.
A better way to add background to your text:
As I'm guessing you all know, click-able text should always have a background. Now, a common mistake is to create a separate image meter behind it to achieve this. However, this isn't necessary! If you want your text to have a background, just add a SolidColor value to the string meter. (Thanks to Kaelri)
A better way to show/hide meters:
When you want an event to hide or show several meters add Hidden=#Variable# and DynamicVariables=1 to the meters you want to hide/show. Then make the event trigger the !RainmeterSetVariable bang. This is more effective than using endless !execute= commands for the same job.
Other Optimizing Tips
Repeated values:
Use variables for code with several or long values that are repeated in the skin (E.g. Regular Expressions, Substitutes, !Execute= with several bangs, etc.). This basically means: Less code! Which is awesome. In addition, it's obviously easier to edit it if you want to change it later.
I actually don't recommend the one to speed up the "shutdown" of Rainmeter. The difference in shutdown time is so negligible, unless you have dozens of skins running, that the enormous amount of work and reduction in flexibility far outweighs any benefit in my opinion. To each his own, and I agree completely with the others, but I'd have to give that one a thumbs-down.
jsmorley wrote:I actually don't recommend the one to speed up the "shutdown" of Rainmeter. The difference in shutdown time is so negligible, unless you have dozens of skins running, that the enormous amount of work and reduction in flexibility far outweighs any benefit in my opinion. To each his own, and I agree completely with the others, but I'd have to give that one a thumbs-down.
Hehe, I see why most people wouldn't care for that approach, but for me it's perfect as I only use my own code, I'm not planning on changing it completely any time soon and I never use the drag function.
Hmm, this Hide/Show thing with DynamicVariable is exactly what I´ve been searching for.
It´s very useful for those tabbed skins (like mine )
But it somehow doesn´t really seem to work as it should.
At least Hiding/Showing works perfect, but some meters are repositioned and image are to small, or missing parts :shock:
I only tried it 5 minutes, but it´s a bit weird. Hmm ... maybe it´s my skin that´s cauing it.
Anyone else having this?
btw (if it´s helpful to solve my problem): I´m having lots of image positioned with the #SCREENAREAWIDTH# Variable ...
I use dynamic variables to hide/show all of the time and have never had problems with positioning or image size. It must be something else in your code that is causing these problems. I couldn't say what without seeing it though.
P2C wrote:Hmm, this Hide/Show thing with DynamicVariable is exactly what I´ve been searching for.
It´s very useful for those tabbed skins (like mine )
But it somehow doesn´t really seem to work as it should.
At least Hiding/Showing works perfect, but some meters are repositioned and image are to small, or missing parts :shock:
I only tried it 5 minutes, but it´s a bit weird. Hmm ... maybe it´s my skin that´s cauing it.
Anyone else having this?
btw (if it´s helpful to solve my problem): I´m having lots of image positioned with the #SCREENAREAWIDTH# Variable ...
As Alex2539 said, it has to be something else in your code that's causing it. However, when I come to think of it, I think there are some bugs reported with dynamic variables. I'll look into it. Anyways, why don't you just post the code and we'll have a look at it?
I just made an interesting find about measures that may be the reason some skins are slow and stuttery while others that are just as complex aren't.
I was putting together an analog clock, and I was frustrated that every time the second hand was about to reach a new minute it would seize up and spike the CPU 20%. This was the code that was causing the problem:
Whether or not CALC chaining was the problem (maybe I just exposed a memory handling bug in Rainmeter), it sure helped a lot to do without it.
EDIT: After doing a LOT of starring at my screen, I've determined the stutter to be caused by NOD32 4.0.467's real time file system protection, specifically on file open and file creation. Rainmeter itself was quite steadfast through a CPU stress test.
Last edited by killall-q on December 30th, 2009, 2:59 am, edited 1 time in total.
The problem you were experiencing was probably related to the fact that when a Calc measure uses a value from another measure it will always be one update behind. So when you get the value of a Calc measure that's already getting the value of another measure, you will be two full updates behind the original value. If you don't take steps to compensate for this, it can sometimes have undesired effects.
