It is currently April 23rd, 2019, 11:04 am

[Request] Way to use in-memory images

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

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

jsmorley » December 13th, 2018, 1:04 am

rxtd wrote:
December 13th, 2018, 12:59 am
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.
I'm sure Brian or theAzack9 will have some time soon to take a look at this bit...
User avatar
Brian
Developer
Posts: 1861
Joined: November 24th, 2011, 1:42 am
Location: Utah

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

Brian » December 14th, 2018, 7:52 am

rxtd wrote:
December 13th, 2018, 12:59 am
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.
Not sure how this improves performance at all, but it does appear to be backwards compatible and takes no new resources. (See my post on github about my other concerns.) Also, dirty and unreliable...you didn't use those terms on github, and now I am considering this even less.



We have lightly talked about this in the past (basically when dgrace gifted us with the AudioLevel plugin). I believe at the time we were concerned with changing the plugin interface to allow for a different "way" of getting data to an image meter. We still support our "old" plugin interface, and our current plugin interface, and adding a third option specifically to pass data to the Image meter seems very sketchy at best.

Personally (just me, not the Rainmeter team), I have always thought about doing a "meter" plugin interface that would allow plugins to draw directly on the canvas (or some sandboxed version of it) - or at least let the plugin draw something on its own (which you touched on earlier, only this would draw at the correct timing instead during the measure update cycle). Obviously there would be challenges to figure out such as: we probably don't want to give total control of the canvas to the plugin in case the plugin fails, combining the measure interface and meter interface in 1 plugin might be difficult, dealing with a meter's general options might require some careful thought on accessing the data that is not normally exposed to the plugin...and I am sure there would be a whole host of things to consider.

So, even IF the whole team agrees to pursue this feature, you can imagine the project it would be to get something like this up and running. Our development team's availability is pretty scarce lately and we have quite a big "laundry" list to get done before we could even attempt to tackle this. I am certainly not saying this won't ever happen, but our time is limited for the next "while".

As always, we welcome pull requests on github and try to attempt to "review" them when time allows.

-Brian
rxtd
Posts: 94
Joined: April 30th, 2017, 11:51 am

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

rxtd » December 14th, 2018, 9:29 am

Brian wrote:
December 14th, 2018, 7:52 am
Also, dirty and unreliable...you didn't use those terms on github, and now I am considering this even less.
I mean it in the sense that it doesn't provide a way to keep the file in the memory. When we use FILE_ATTRIBUTE_TEMPORARY, we rely on the fact, that Windows has enough spare memory to keep our file in cache. And nobody knows how much is the amount of "spare memory" in the moment. Sone program can read another file, and Windows can decide that cache for that program is more important, then for ours.
As I said, I tested it, and on my computed even 10 MB files can ignore cache, and are written to disk as usual, not temporary, files. If I write it every 16 ms, it's really bad. That's what I call "dirty and unreliable".

And regarding potential problems: I wrote about them in the answer to your first question on github.
Brian wrote:
December 14th, 2018, 7:52 am
We have lightly talked about this in the past (basically when dgrace gifted us with the AudioLevel plugin). I believe at the time we were concerned with changing the plugin interface to allow for a different "way" of getting data to an image meter. We still support our "old" plugin interface, and our current plugin interface, and adding a third option specifically to pass data to the Image meter seems very sketchy at best.
1. Well, personally I don't see problems in extending plugin interface with new functionality. Changing existing — that is what really hard, when the backward compatibility is needed.
You can make the function that returns (generates) file data. No difference from reading actual files. It can potentially be reused in many places. I feel like it's good plugin interface extension.
2. The main and only problem is that plugin interface lacks just one function "GetPluginInterfaceVersion". Adding it would solve all (or almost all) problems with supporting several versions of the interface.
If only it was there since plugin support was added to Rainmeter... I saw the code that determines plugin interface version, and it's terrifying.
Brian wrote:
December 14th, 2018, 7:52 am
Personally (just me, not the Rainmeter team), I have always thought about doing a "meter" plugin interface that would allow plugins to draw directly on the canvas (or some sandboxed version of it) - or at least let the plugin draw something on its own (which you touched on earlier, only this would draw at the correct timing instead during the measure update cycle). Obviously there would be challenges to figure out such as: we probably don't want to give total control of the canvas to the plugin in case the plugin fails, combining the measure interface and meter interface in 1 plugin might be difficult, dealing with a meter's general options might require some careful thought on accessing the data that is not normally exposed to the plugin...and I am sure there would be a whole host of things to consider.
I also have similar thoughts.
But I can imaging the amount of work that such project would require. And such meter plugin interface will also kind of lock Rainmeter drawing techniques.
That's why I proposed transferring images only.
User avatar
Smurth
Posts: 5
Joined: February 2nd, 2019, 2:10 pm

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

Smurth » February 2nd, 2019, 2:33 pm

This could be done by monitoring WindowMessages to get a handle pointing to the image to be display.
It would be really usefull...