It is currently March 28th, 2024, 10:56 am

[Request] Way to use in-memory images

Report bugs with the Rainmeter application and suggest features.
rxtd
Posts: 100
Joined: April 30th, 2017, 11:51 am

[Request] Way to use in-memory images

Post by rxtd »

It would be very convenient to have the ability to use generated images.

Why I think it is needed:
There are things that are only needed in meters. They don't benefit from saving to disk. They will be deleted or overwritten after only one read.
For now Rainmeter has Shape meter that makes it easy to draw vector graphics but not everything can be presented in vector form. You can only draw things with flat or gradient surfaces. If I ever want to draw some raster image using Shape meter it would require me to define as many rectangle shapes as there are pixels in the image, and that would be extremely slow down Rainmeter.

So I can only use real images. And the problem is: Rainmeter can only load them from disk.
You would say that it's not a big deal. And I agree with that... in case the image is static. It can be written to disk one time, and then you use it.
But writing to disk is a problem if you need a dynamic image. Let's say, it changes every 16 ms, and you want to show it in the skin. Writing it to disk will cause quite a bit of... um, written data.

For example, if you file is random, have resolution of 400×300, 32 bits per pixel, it will be ~0.5 MB of size. It isn't healthy for neither SSD nor HDD.
Such picture would write to disk 0.5 MB per write, 29 MB per second, 108 GB per hour, 2.5 TB per day, almost 1000 TB per year. SSDs don't like this.
And in case of HDD: what speed of operations does it have? Probably about 100-150 MB/s maximum continuous speed for a fresh disk, and more likely about 50-80 MB/s in case of a fragmented disk. Probably be even worse for 2.5" disks for late disk tracks. Rainmeter would solely eat up about half of the possible disk performance.

And yeah, you can just use images of lower resolution, and show it with mush lower framerate. Well, I don't take this as valid argument. It just won't look as good. If it was possible (without that much of a performance impact), I would totally use images with the resolution I need, at the framerate I need.
You also can try to compress the image before writing. It may help (or may not, if the image does not compress well), but it will require additional CPU time to compress and then decompress data.

And even if I reduce size of the image, there could be just too many of them. Imagine a large skin, that mostly use generated images to show information. And let there be several such skins. It would slow down your computer quite a bit now, but it would be very cheap if we use memory only, without writing to disk, without unnecessary compression.

In case you are thinking now "what the hell do you need dynamic images for?!" here are some examples:
1. Line meter is nice. But not perfect. I really miss several features that it could have.
  • Respecting MinValue — can't be done. May be mitigated with use of several Line meters and new Container option.
  • Plot shadow effect — can't be done. Mixing Line with Histogram does something like this but reduces performance and sometimes doesn't look very good.
  • Value-based colors — can't be done.
  • Show values stationary, updating them as in ring buffer — can't be done.
It worth noting that probably all of this could be done with lua- or plugin-constructed shape meter, but few dozens of such meters of decent size updating with least 1-2 FPS would have big performance impact.
2. Histogram meter would also benefit from respecting MinValue, value-based colors, and stationary values.
3. You simply can't show something like spectrogram without raster images. And in case of audio analysis the spectrogram should really update with at least 30 FPS, better 60 FPS. And it's the case the where image can be quite big, and is incompressible. And there could be several such images as you have more than one audio channel.
4. Support for animations.
And there are a lot of places where you can use static in-memory images instead of temporary files. Like, for example, download file from the internet and feed it into Image meter.

I don't think that Rainmeter will ever make such modifications to Line/Histogram meters.
Spectrogram is impossible to implement without making new meter that will also calculate values that it will show (or adding array type of measure values). And I really don't think that it will be implemented ever.
I guess that support for animations is also not gonna be added in Rainmeter as it's still not implemented. And even if it is added—there are a lot of formats, and some of them are rare.
That's what plugins are for: anyone can add something that he considers useful without bloating the program!
So why don't allow plugins to generate images?

Actually, I have some thoughts against it.
"graphics is drawn by Rainmeter, measures only provide values"
Well, I don't think it's that big of a deal. Graphics can already be drawn by something external, with Image meters showing it. My proposal just make it work better.
"every measure has number and string values, all else is an external resource"
Come to think about resources: why not? If there were some other resources, you could allow them to be loaded from memory as well. Maybe, images, fonts, scripts? I don't know. It could work just like with files, just that the file is already loaded into memory.
But I'm not sure if it could be as useful as in-memory images.
How I see the implementation:
Allow image path to be URI.
memory://[config.name.]<measureName>/<some>/<path>

And then the list of plugin functions can be updated to have something like this:
DWORD* ResolveImage(void* data, int pathPartsCount, const WCHAR* path[], int *width, int *height);
It should set width and height to proper values and return a pointer to array of (*width) × (*height) values in ARGB format (or any other you like). Basically, a bitmap.
Or nullptr in case it doesn't have image that matche specified path.
By the way, there is a dirty and unreliable hack that allows one to share files without writing anything to disk. And yeah, it's just dirty and unreliable, but it does not requires any changes in Rainmeter. Well, almost.
You can open a file with FILE_ATTRIBUTE_TEMPORARY as an attribute to CreateFileW function, and the file should stay in cache only. But Windows can flush it on disk in any moment, it if want's to. For example, on my system I were only able to create 1-2 MB file. Just 10 MB—and file is written to disk. And I have about 8 GB of free memory. I feel that it's possible that Windows just ignore this flag and always write file, if some conditions are met. For example, if there is less memory available.
It would be great though to at least have the ability to make small and unreliable in-memory files. It's better than nothing.
Unfortunately, Rainmeter can't open images created this way because it doesn't specify FILE_SHARE_WRITE when opening files. But I can't close the file handle because as soon as I do it, the file is flushed to disk.
Can you please accept my pull request that fixes this?
Last edited by rxtd on December 12th, 2018, 11:43 pm, edited 2 times in total.
User avatar
kyriakos876
Posts: 919
Joined: January 30th, 2017, 2:01 am
Location: Greece

Re: [Request] Way to use in-memory images

Post by kyriakos876 »

I don't mean to sound rude, but damn... That's a lot of stuff... This is Rainmeter, a simple tool to help you monitor stuff with style. If you see it as a video creating software you're looking at it the wrong way. The fact that it can do all the things it's doing right now is already more than it was built to do. I think what you're looking for is Adobe After Effects. You can do as many images with whatever shadows and whatnot in whatever 80k resolution you wish. But don't expect to create anything that uses images like it's call of duty or something...
rxtd
Posts: 100
Joined: April 30th, 2017, 11:51 am

Re: [Request] Way to use in-memory images

Post by rxtd »

kyriakos876 wrote: December 12th, 2018, 11:15 pm I don't mean to sound rude, but damn... That's a lot of stuff... This is Rainmeter, a simple tool to help you monitor stuff with style. If you see it as a video creating software you're looking at it the wrong way. The fact that it can do all the things it's doing right now is already more than it was built to do. I think what you're looking for is Adobe After Effects. You can do as many images with whatever shadows and whatnot in whatever 80k resolution you wish. But don't expect to create anything that uses images like it's call of duty or something...
I don't want Rainmeter to create 80k images like in photoshop.
Actually, the main thing I want to do with it is to show audio spectrogram. That's where I got the idea.
Something like this:
2018-12-13_06-17-17.png
Dead simple.
There are some other things I can come up with, and I listed some in the post.

What I want from rainmeter is to read image data from my plugin instead of a file.
Dead simple.
It will require some changes but it's not that big amount of work as you are talking about.

And speaking about monitoring stuff. Shape meter is not needed, Container is not needed, Image meter is not needed, Button meter is not needed, transparency is not needed. Even Rainmeter is not needed: you can just use Task Manager/PerfMon/ResMon/Process Explorer or anything other you like.
And 90% of skins are not needed as they are created to be nice, and not to actually monitor something.

Rainmeters brings comfort in your lives in case of monitoring and gives us the ability to draw some nice colored translucent windows. It's not just the monitoring tool for me.
User avatar
kyriakos876
Posts: 919
Joined: January 30th, 2017, 2:01 am
Location: Greece

Re: [Request] Way to use in-memory images

Post by kyriakos876 »

That's why I said that "it's already doing a lot... And the way I meant monitor stuff I didn't mean it in a robust way... I said "Monitor with style" for a reason :) and obviously that's not what it's built for... It's a canvas and some colors to paint on, but if you need some crazy calipers to do perfect circles, you can't expect a simple setup to provide such complicated thing. Again, not trying to be mean, just sharing my opinion on this because I've thought about something similar some time ago.
rxtd
Posts: 100
Joined: April 30th, 2017, 11:51 am

Re: [Request] Way to use in-memory images

Post by rxtd »

kyriakos876 wrote: December 12th, 2018, 11:34 pm That's why I said that "it's already doing a lot... And the way I meant monitor stuff I didn't mean it in a robust way... I said "Monitor with style" for a reason :) and obviously that's not what it's built for... It's a canvas and some colors to paint on, but if you need some crazy calipers to do perfect circles, you can't expect a simple setup to provide such complicated thing. Again, not trying to be mean, just sharing my opinion on this because I've thought about something similar some time ago.
Well, I guess you won't say that showing the spectrogram is not monitoring.
And that showing animations (let's say, animated gifs) has nothing to do with the "style".
And that Line meter is useless. One of my ideas is to add few more options to it. For example, the lack respect to MinValue is this really small thing that sometimes really annoys.

And, as I said
rxtd wrote: December 12th, 2018, 10:35 pm That's what plugins are for: anyone can add something that he considers useful without bloating the program!
It doesn't matter how crazy plugin author's ideas are if Rainmeter only shows images.
User avatar
kyriakos876
Posts: 919
Joined: January 30th, 2017, 2:01 am
Location: Greece

Re: [Request] Way to use in-memory images

Post by kyriakos876 »

Again, "Monitor with style" a generic use, don't stick to it. I do agree with you in the plugin part, if you have something stable and reliable, then that's great and you should share it with the world. But my main point was none of this. My point was just that you asked for a variety of stuff on your first post. Also, you used the word "hack". If you were using it as a metaphor with the meaning of "a weird way" then that's okay, but hacking windows isn't really what rainmeter does if that's how you meant it. I can't even write the registry because it's considered hacking. I mean, I obviously can... Nobody is going to check my whole code what it's doing, but I'm not going to, because that's just not Rainmeter... Again, if you meant is a metaphor, don't mind the sentence above.
rxtd
Posts: 100
Joined: April 30th, 2017, 11:51 am

Re: [Request] Way to use in-memory images

Post by rxtd »

kyriakos876 wrote: December 12th, 2018, 11:59 pm Again, "Monitor with style" a generic use, don't stick to it. I do agree with you in the plugin part, if you have something stable and reliable, then that's great and you should share it with the world. But my main point was none of this. My point was just that you asked for a variety of stuff on your first post. Also, you used the word "hack". If you were using it as a metaphor with the meaning of "a weird way" then that's okay, but hacking windows isn't really what rainmeter does if that's how you meant it. I can't even write the registry because it's considered hacking. I mean, I obviously can... Nobody is going to check my whole code what it's doing, but I'm not going to, because that's just not Rainmeter... Again, if you meant is a metaphor, don't mind the sentence above.
Please, read my post with more attention.
The only place I mentioned word "hack" is the very end. And it has nothing to with my request. It's the opposite: I don't want to use hacks, so I want to be able to use in-memory images.
User avatar
kyriakos876
Posts: 919
Joined: January 30th, 2017, 2:01 am
Location: Greece

Re: [Request] Way to use in-memory images

Post by kyriakos876 »

You are probably right. I didn't understand that part correct the first time. Pardon me :???:
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: [Request] Way to use in-memory images

Post by jsmorley »

I personally don't have a strong opinion about this request, but let me lay out how we evaluate these things.

First, we start with some basic facts of this project:

1) Backwards compatibility is fundamental.
2) Performance and stability is fundamental.
3) We have very limited resources, and those we have are time-constrained.

So we ask a pretty simple series of questions:

Is this change something that can be done with zero impact on backwards compatibility, and if so, can it be done in a way that performs well enough, even when "pushed" by our creative skin authors, to not disappoint our users, and if so, is this something that the majority, or at least a large portion, of the user-base has a need for or would use? If all of those come back with "yes", then we still have to ask, How much effort is this going to require, and where does it fall in the priority list of things we would like to get accomplished with our limited resources?

This will be evaluated in that light, as all requests are. I can't predict what decision we will come to, or have any clue as to when something like this might percolate to the top of the priority list.

Having said that, and with the understanding that it is in no way up to me, let me weigh in. I don't like it. First, I think it is an "edge case", with a very limited audience, maybe an audience of 1. Second, I think this can only add to what I think is a terrible thing in Rainmeter, the flood of audio "visualizer" skins that all run like crap. They require the skin to be set at Update=16, and just use a boatload of CPU. Hey, it's your computer, and you can give your CPU heatsink a workout to your heart's content, but I'm hesitant to introduce another feature that overworks Rainmeter to accomplish the kind of real-time animations that Rainmeter was never designed for.
rxtd
Posts: 100
Joined: April 30th, 2017, 11:51 am

Re: [Request] Way to use in-memory images

Post by rxtd »

jsmorley wrote: December 13th, 2018, 12:49 am
Thank you for considering my request.
I want to add two things:
1. If you decide that it can be implemented, but you don't have enough resources, then I can help with it. Tell me the way you want it to be implemented, and I'll write the code. I think I will have enough free time in the January.
2. I'm pretty sure the pull request I mentioned in the first post is backward compatible, improves performance and requires zero resources to be implemented. Even if you decide not to add support for in-memory images, it will allow plugins to do something like this.
Post Reply