Negative Space

[kylergs]

--V2--

v2 http://kylergs.deviantart.com/art/Negative-Space-VU-Meter-534037505
https://imgur.com/a/xJ1Vt

--V1.2--
v1.2 https://imgur.com/UvIgMS5
--V1--
First try at OC

Images Here:
https://imgur.com/a/aREJs

You need desktopVUmeter-2 to use the settings screen on the visualiser

Please give feedback, thanks

[shAdowz]

How did you make a media player?

[kylergs]

He's the code if you want to take a look

http://pastebin.com/A5Hq1aUd

It just calls a the stuff from now-playing

[fonpaolo]

Update=0 isn't really a good idea...
Update

[jsmorley]

Update=0 isn't really a good idea...
Update

Right, Update=0 is really effectively Update=16. There are two reasons to be absolutely certain that you need that low an Update rate.

1) Rainmeter will use relatively much more CPU. This may or may not be an issue, depending on the design of the skin. A well designed skin that is using UpdateDivider on measures and meters that don't need the speed should be fine with a low update rate, but it is not hard to write one that can be a bit of a pig.

One subtle hint. The more a skin has actual "images" that have W and H set on them, the worse the CPU usage will be at a low Update rate. Images are resized during the "redraw" cycle of the skin, and even if the W and H are the same as the size of the actual image, the resize will be done. Redraw will be done on each skin update, can't be controlled by UpdateDivider or anything else, and so Update=16 and a bunch of images is a recipe for poor performance. Resizing images is relatively expensive in the Rainmeter world.

2) Any thoughts of using the Update rate of the skin to control any kind of "timing" or to expect really smooth reliable animations when the Update rate is really low, probably under 25 or 50, will be a disappointment. At Update=16, depending on what else Rainmeter has to do in all your loaded skins, you can get lots of "skipped updates" in your skin, and that can make any construct that assumes that "XX Updates equals YY time" entirely unreliable, and can cause jerkiness in animations.

In almost all cases, Update=16 does not mean "update every 16 milliseconds". It means "try to update every 16 milliseconds". There is a "queue" that all this works in, that has a lower limit of 16 milliseconds, and all skins share that queue.

[kylergs]

Thanks for the advice guy's I've put a bit of effort into reducing what is actually redrawn and when. I presume UpdateDivider=-1 on the images helps?

I managed to get it down from 8% CPU at it's worst to hovering around 1.5% with the launcher open.

New Screenshot https://imgur.com/UvIgMS5

Down to .5% worst now, thanks for the advice

[jsmorley]

Thanks for the advice guy's I've put a bit of effort into reducing what is actually redrawn and when. I presume UpdateDivider=-1 on the images helps?

It really does not... There is almost NEVER any reason to use UpdateDivider on a meter, although it is supported. The "work" that a meter does during an Update is just really minimal. While you can set UpdateDivider=-1 on meters and then control their update with OnUpdateAction or OnChangeAction on measures, it's just not going to save you much.

The real "work" that is done with Image meters is done in the "redraw" cycle of the skin. That mostly has to do with resizing Image meters that have W and H on them. It has nothing to do with UpdateDivider, and is purely controlled by the Update in [Rainmeter].

The best advice I can give for a skin with a lot of Image meters that have W and H on them is to try to have the largest Update in [Rainmeter] that properly supports the functionality of your skin.

What I try to do with "launchers" is to have that functionality in its own skin. Then I can set Update=-1 in [Rainmeter] (basically never update after the initial load) and control everything with mouse over/leave/up actions. That way the skin uses zero CPU, as it is never updated, and only does something at all when you tell it to with the mouse.

Code: Select all

[Rainmeter]
Update=-1
DynamicWindowSize=1
AccurateText=1

[MeterLaunch]
Meter=Image
H=64
PreserveAspectRatio=1
ImageName=#@#Images\RainmeterLogo.png
SolidColor=0,0,0,1
AntiAlias=1
MouseOverAction=[!SetOption MeterLaunch ImageTint 140,247,129][!UpdateMeter MeterLaunch][!Redraw]
MouseLeaveAction=[!SetOption MeterLaunch ImageTint ""][!UpdateMeter MeterLaunch][!Redraw]
LeftMouseUpAction=["http://rainmeter.net"]

[kylergs]

Thanks, I put the update up a bunch on that skin but because I put the album cover in there it needs to update occasionally. I'll probably come back and separate it into a different skin so it can only update itself but I've spent so long in GIMP today I feel like I should go outside.

Thanks for the advice, I've been thinking about a more resource heavy, interactive skin so the optimisation stuff will come in useful.

I've put the newest version in the main post.

[jsmorley]

Thanks, I put the update up a bunch on that skin but because I put the album cover in there it needs to update occasionally. I'll probably come back and separate it into a different skin so it can only update itself but I've spent so long in GIMP today I feel like I should go outside.

Thanks for the advice, I've been thinking about a more resource heavy, interactive skin so the optimisation stuff will come in useful.

I've put the newest version in the main post.

I need to fully test, which I will do, but I think the other thing that can really help is if you don't use W and H on Image meters. That means that the actual image files need to be the size you are going to want in the skin, and may be more work in GIMP or maybe not even practical in your case, but without the "resizing" in the redraw cycle, I suspect the skin will use less resources.

[kylergs]

I need to fully test, which I will do, but I think the other thing that can really help is if you don't use W and H on Image meters. That means that the actual image files need to be the size you are going to want in the skin, and may be more work in GIMP or maybe not even practical in your case, but without the "resizing" in the redraw cycle, I suspect the skin will use less resources.

Does that matter with BarImage? I had inadvertently already done that with everything except the VU-Bars. I'll have it remove the option from the style when it changes them

Is it better to have solid colour defined in the skin with W/H or a solid colour image at the correct size?