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.