It is currently September 23rd, 2020, 1:45 pm

BUG: Massive performance cost for 2 image and string meters

Report bugs with the Rainmeter application and suggest features.
User avatar
jsmorley
Developer
Posts: 21386
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: BUG: Massive performance cost for 2 image and string meters

Post by jsmorley »

eclectic-tech wrote: April 7th, 2020, 11:51 pm Only a "real" coder would look for an invisible character! :p
Besides resizing 2 almost full screen height image to 250 pixels high every second; which is also CPU intensive... :uhuh:
Nice catch! :great:
Resizing even two large images once a second isn't a huge deal. Doing it every 16 milliseconds is...
User avatar
eclectic-tech
Rainmeter Sage
Posts: 4114
Joined: April 12th, 2012, 9:40 pm
Location: Cedar Point, Ohio, USA

Re: BUG: Massive performance cost for 2 image and string meters

Post by eclectic-tech »

jsmorley wrote: April 8th, 2020, 12:02 am Resizing even two large images once a second isn't a huge deal. Doing it every 16 milliseconds is...
Maybe I should have said it is "not a good practice"... :uhuh:

Resizing images, if more than a few are used, will increase the CPU load, so I would always suggest resizing all included images, to the desired "normal" dimension, and avoid resizing at all in the skin. Graphics are not Rainmeter's "strong suit". :)
coldshiver
Posts: 9
Joined: January 8th, 2014, 4:06 am

Re: BUG: Massive performance cost for 2 image and string meters

Post by coldshiver »

OMG, thank you, nice find. I feel so stupid. Must have happened while copying an online example into the skin to start out. Sneaky invisible characters are always a pain in the ass.

Consider this bug post, not a bug. Should i close it? Or should an admin do this? Whats the drill here?
coldshiver
Posts: 9
Joined: January 8th, 2014, 4:06 am

Re: BUG: Massive performance cost for 2 image and string meters

Post by coldshiver »

eclectic-tech wrote: April 8th, 2020, 2:21 am Maybe I should have said it is "not a good practice"... :uhuh:

Resizing images, if more than a few are used, will increase the CPU load, so I would always suggest resizing all included images, to the desired "normal" dimension, and avoid resizing at all in the skin. Graphics are not Rainmeter's "strong suit". :)
Yeah i mite consider doing a resize up front i just hate doing that for every image all the time, if performance is no longer an issue i'l be fine just updating the skin more slowly. I guess rainmeter could optimize redrawing an image meter by caching the resized image, maybe a caching attribute on an IMAGE meter, or something like noResize or fixedSize property would be welcome so rainmeter does not have to resize the image on every update, since this should not be needed for most skins.
User avatar
eclectic-tech
Rainmeter Sage
Posts: 4114
Joined: April 12th, 2012, 9:40 pm
Location: Cedar Point, Ohio, USA

Re: BUG: Massive performance cost for 2 image and string meters

Post by eclectic-tech »

coldshiver wrote: April 8th, 2020, 6:01 pm Yeah i mite consider doing a resize up front i just hate doing that for every image all the time, if performance is no longer an issue i'l be fine just updating the skin more slowly. I guess rainmeter could optimize redrawing an image meter by caching the resized image, maybe a caching attribute on an IMAGE meter, or something like noResize or fixedSize property would be welcome so rainmeter does not have to resize the image on every update, since this should not be needed for most skins.
You can add UpdateDivider=-1 to images that will not change after loading the skin. They will be sized one time when the skin is loaded, then not updated until explicitly told to, or the skin is refreshed.
Correction (see post below)... :oops:
User avatar
jsmorley
Developer
Posts: 21386
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: BUG: Massive performance cost for 2 image and string meters

Post by jsmorley »

eclectic-tech wrote: April 8th, 2020, 6:07 pm You can add UpdateDivider=-1 to images that will not change after loading the skin. They will be sized one time when the skin is loaded, then not updated until explicitly told to, or the skin is refreshed.
Sorry, but that is just not right. Any resizing of an image done with W and / or H is done in the "redraw" cycle of the skin, which you simply can't avoid, other than with the overall skin Update. That work is not part of the update of the "meter".

We have given some thought to caching a "resized" version of the image, but that gets tricky when the image content or image size is in any way "dynamic". As someone once said, you don't want the solution to be worse than the problem.
coldshiver
Posts: 9
Joined: January 8th, 2014, 4:06 am

Re: BUG: Massive performance cost for 2 image and string meters

Post by coldshiver »

jsmorley wrote: April 8th, 2020, 6:09 pm Sorry, but that is just not right. Any resizing of an image done with W and / or H is done in the "redraw" cycle of the skin, which you simply can't avoid, other than with the overall skin Update. That work is not part of the update of the "meter".
Hmm so the only current solution is to either resize the image files used in the skin or to have a really slow overall skin update time then.
User avatar
jsmorley
Developer
Posts: 21386
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: BUG: Massive performance cost for 2 image and string meters

Post by jsmorley »

coldshiver wrote: April 8th, 2020, 6:11 pm Hmm so the only current solution is to either resize the image files used in the skin or to have a really slow overall skin update time then.
Exactly.

Keep in mind that this should not be overblown. While the work done to resize an image is a relatively large amount, it is still a tiny, tiny amount unless you have just boatloads of huge images you are making small, or have a really low Update rate. The key is "relatively large".

With a skin with Update=1000, you will never see any issue with resizing images.

If you want to be anal-retentive about it though, you would want to physically size the image(s) to the size you need, and not use any W and / or H at all. The more "difference" there is between the W / H and the real size the more work is done, but even if you use W and H and set them to the physical size, some work is done to evaluate the image. A lot less work, but some.

This is why where possible, I like to use Shape meters in place of actual external images. Shape meters are only drawn when the meter is updated. Not always possible or practical of course.
coldshiver
Posts: 9
Joined: January 8th, 2014, 4:06 am

Re: BUG: Massive performance cost for 2 image and string meters

Post by coldshiver »

jsmorley wrote: April 8th, 2020, 6:12 pm Exactly.

Keep in mind that this should not be overblown. While the work done to resize an image is a relatively large amount, it is still a tiny amount unless you have just boatloads of huge images you are making small, or have a really low Update rate. The key is "relatively".

With a skin with Update=1000, you will never see any issue with resizing images.
Cool, thanks for everything. I won't have allot of images really, about 10 max probably. Although i will be adding and removing images to it regularly because its a release countdown display or for events or whatever really. And in my current form it could even update hourly. :thumbup:

This is the skin i'm using myself, mite release it at some point but it's nothing fancy. It has a normal "In x days" and a digital second countdown display, but ofcourse when using that the skin update rate will have to be 1000 atleast. For the days it can be really high like hourly or more.

It's built up dynamically and all i have to do is put an image file with the name "2020-01-05-whatever.jpg" in a directory and it shows up in my skin.

Image
Last edited by coldshiver on April 8th, 2020, 7:10 pm, edited 1 time in total.
User avatar
jsmorley
Developer
Posts: 21386
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: BUG: Massive performance cost for 2 image and string meters

Post by jsmorley »

Well shit... I was just informed by brian that this was changed when we moved from GDI+ to D2D for our graphics engine. We now DO in fact cache "resized" version of all images, and so the work is in effect done in the update of the "meter" and not in the update of the "skin".

Sorry for leading you down a rabbit-hole here.... ;-)