12-07-2015 01:10 PM
Hi gdargaud,
There is no way to disable the generation of EVENT_MOUSE_MOVED--swallowing the event will result in CVI ignoring future occurrences of the event (i.e. even if the event is generated, no callbacks will be called), but it will still be generated.
Regarding SetSleepPolicy's effect on Linux, this may depend on the particular distribution of Linux that the user is running. LabWindows/CVI support for Linux is limited to the Run-Time Engine, which is designed to simply run programs developed in CVI. So, there is no way to tell for certain whether SetSleepPolicy will work the same way that it does on Windows without a bit of trial and error.
12-08-2015 06:00 PM - edited 12-08-2015 06:03 PM
Despite the discussion about the effect of sleep policy on Linux which I know nothing of, setting a sleep policy too aggressive in a single-threaded environment is risky in my opinion as it may lead to the user interface being totally or heavily unresponsive in case of long-lasting functions or timer callbacks firing very frequently and consuming too much processor time. Consider that there is no intermediate level between sleep some and no sleep.
In other words, I don't consider SetSleepPolicy the right instrument to address the case of "slow" user interface, which is the argument we are discussing in this thread.
12-09-2015 03:07 AM
Hi Roberto,
SetSleepPolicy is certainly not the best way to make a user interface move responsive, but during some time-consuming tasks it may help. In addition, default value for sleep policy is VAL_SLEEP_MORE, if developped application is really heavy switching to VAL_SLEEP_SOME can be considered.
Anyway, I am convince that the best way to make the user interface more responsive is not to use SetSleepPolicy but to limit the refresh operations to visible controls/indicators, to discard panels as soon as there are not used (if there are not to long to rebuild), and to limit the refresh rate using some kind of timer callback because the user is generally much slower than the interface .... and I think I still forget a lot of things.
On my side I am using something that I think is not too far from what you suggest. I have implemented an application event queue. Any panel can queue an event and a timer callback is in charge to process events on a regular base (500ms) and call panel event callback only when the panel is visible. Events can be broadcasted to all panels or target a single panel.
Best regards,
Stephane
12-09-2015 05:02 AM
Hi Stephane,
I was erroneously assuming you were proposing a switch from "sleep some" to "do not sleep". On the contrary, switching from "sleep more" to "sleep some" makes perfectly sense. On my defense consider that I use "sleep sone" as the default sleep policy in my programs.
12-09-2015 05:24 AM
I've never really understood what this sleep policy does. I remember it having an impact at the time of Win95, but not since Win2K. To refresh my memory I just looked at the CVI examples using it, there are 3 of them, all based on OpenGL. But changing the sleep policy has no effect that I can tell. I didn't test them under Linux as the OGL libs seems to be missing on my install (I don't know if they are available), instead I did a tiny canvas mouse drawing example, and again, no difference.
12-09-2015 03:54 PM
As of my experience, the effect of sleep policy setting can be better observed when multiple program are running concurrently or in multithreaded programs.
The programmer can decide to grant to a program or thread the whole processor time (VAL_SLEEP_NONE) or to leave more or less space to other programs / threads in the other cases. It seems difficult to me that a single program can significantly changes based on sleep policy settings if executed alone on well dimensioned systems, unless explicitly structured to stress the system.