It is currently March 28th, 2024, 11:42 am

second/third screen preview box

Get help with creating, editing & fixing problems with skins
User avatar
dgrace
Developer
Posts: 265
Joined: June 28th, 2014, 8:32 am
Location: Tokyo, Japan
Contact:

Re: second/third screen preview box

Post by dgrace »

And yeah, mine crashed too. Going to give up for the night on this one. Thanks for helping to test.

dave
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: second/third screen preview box

Post by jsmorley »

We were wondering why you are using a #Variable# at all?

Why not have options in the plugin measure just define an "offset" from the current mouse position. Something like:

Code: Select all

[MeasureScreen]
Measure=Plugin
Plugin=ScreenShot
MouseXOffset=-100
MouseYOffset=-50
ScreenCaptureW=200
ScreenCaptureH=100
OutputImage=#CURRENTPATH#frame.bmp
The suspicion is that it might be kinda unsafe to have something setting variables during Reload(). Not sure I follow why the "skin" needs to know the current mouse position anyway. Really only the "plugin" cares. Seems to me that you are using the #Variables# to tell the plugin something it already knows. And what you are telling it is not "now" but "then" anyway.

I could perhaps see some value in being able to display the current mouse position in a string meter, but at least that would just be "output" and not simultaneously "input and output" for the plugin. I still maintain that having the skin "know" the mouse position can at best only be at a level of accuracy that is "up to Update milliseconds ago" anyway. Marginally useful.
User avatar
dgrace
Developer
Posts: 265
Joined: June 28th, 2014, 8:32 am
Location: Tokyo, Japan
Contact:

Re: second/third screen preview box

Post by dgrace »

jsmorley wrote:I still maintain that having the skin "know" the mouse position can at best only be at a level of accuracy that is "up to Update milliseconds ago" anyway. Marginally useful.
I think you're a bit confused about how Rainmeter works. Here's what happens for a skin (look in rainmeter/Library/Skin.cpp, in the Skin::Update function):
  • 1.) Wait until Update timer has expired (the time is specified as Update=X in the .ini file)
    2.) Get WM_TIMER message from windows
    3.) (this part is all inline in the same code)
    • a.) call Update() for each measure (if dynamic variables, this calls Reload() at the start of Update())
      b.) call Update() for each meter
      c.) call Draw() for each meter
There is no possible delay between reading the mouse position in Reload() and doing Update(), Draw() and sending pixels to the hardware. I can't figure out where you got that idea. I'm not pointing it out to make fun of you, but it's good to understand the system. In the case of a mouse action, you'd get a different WM_MOUSE... event from Windows and the skin won't necessarily redraw, so storing the values from those events and using them in Update could impart a delay. Maybe that's what you thought I was doing.

dave
User avatar
dgrace
Developer
Posts: 265
Joined: June 28th, 2014, 8:32 am
Location: Tokyo, Japan
Contact:

Re: second/third screen preview box

Post by dgrace »

jsmorley wrote:We were wondering why you are using a #Variable# at all?

Why not have options in the plugin measure just define an "offset" from the current mouse position.
Because then it no longer works as a fullscreen previewer, per the original poster's request. And by exposing the coords to the script you get the flexibility to control them from Lua or another meter. The plugin just needs to do the low-level work of actually grabbing a chunk of screen and writing it out to an image file.

I still suspect the issue is due to the plugin doing an RmExecute from inside the update. I suspect a cleaner path would be to expose something like RmSkinSetVariable in the plugin API, but it doesn't currently exist and I wanted to try not to hack up the core application if I could avoid it.

dave
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: second/third screen preview box

Post by jsmorley »

dgrace wrote: There is no possible delay between reading the mouse position in Reload() and doing Update(), Draw() and sending pixels to the hardware.
Yeah, sorry, I was thinking about this in terms of setting a #Variable# in an IfCondition or mouse action or some other action in the context of the skin, which generally is going to require that you force an "update" of one form or another so it doesn't wait for the next normal update cycle to react to the change.
Post Reply