Slow user interface

[gdargaud]

Hello all,

I have a program that's been getting fatter and slower as of late (about a hundred panels!). The CVI profiler doesn't work (there's another thread discussing this) but gprof and valgrind run fine on it. I discovered that most of the time is spent inside the cvi runtime engine in functions I have no access to but from some hints I think they are related to the user interface. I have a simple question: If I call SetCtrlVal repeatedly without changing the value (or SetCtrlAttribute without changing the attribute), does the user interface wastes time updating the control in the user interface ?

[Wolfgang]

SetCtrlVal updates the value immediately, no matter what value you set. So if you don't change the value, it's a waste of cpu resources.

[OVR_CZ]

Hi,

    Yes , SetCtrlVal always update the ui imediatelly if control is visible.

    If there is lot of controls for update, i  use SetCtrlAttribute(,,ATTR_CTRL_VAL,)  which does not update ui imediatelly but at once, after callback is ended - so it is much faster.

    (UI update can be forced by ProcessDrawEvents/ProcessSystemEvents is called)

    There are also similar tricks for graph (see attribute ATTR_REFRESH_GRAPH) and table (SetTableCellAttribute (, , , ATTR_CTRL_VAL,) or SetTableCellRangeVals)

[gdargaud]

I'm already using SetCtrlAttribute(,,ATTR_CTRL_VAL,) and ATTR_REFRESH_GRAPH=0 everywhere, so I guess I should try to come up with more event-driven updates.

[RobertoBozzolo · Accepted solution]

In case of a hevy user interface vs. a fast acquisition process I have used a thread safe queue to pass data between the acquisition thread and a slow timer used to update the user interface. The timer works at 2 or 3 hz, while the separate thread is notably faster. I use a 1-element queue with auto flush so that the timer retrieve the last value put in the queue.

This system guarantees that the acquisition thread can run as fast as required while user interface updates do not stress the system unnecessarily.

In the timer of course SetCtrlAttribute (..., ..., ATTR_CTRL_VAL, ...) is mandatory.

[gdargaud]

Sleeping on it is often a good thing. Instead of jumping on your multithread suggestion which would open a whole bag of knots, I did something very simple: in the heaviest UIR timer loop, I added a bunch of ProcessSystemEvents() calls... It's so much more responsive now.

[ElectroLund]

This is anecdotal, but in my experience this can be dangerous.  I have found that the positioning of ProcessSystemEvents() to be tricky and can lead to unexpected behavior.

[gdargaud]

All the UIR stuff is in the same thread and the prog has been running great for a few years usingg this method...

[stef_fr]

HI,

Sometimes, I use SetSleepPolicy(VAL_SLEEP_NONE) to ensure my application is not put in background when waiting for system events and it makes it more reactive. 

[gdargaud]

About that... does SetSleepPolicy has an effect on Linux ? There's no mention of it in the documentation.

And I also have a more general question about the EVENT_MOUSE_MOVED which is generated continuously whenever the mouse is over the program. Isn't that wasteful in terms of CPU if I'm not interested in catching this event ? Any way to disable it ? Would returning 1 to swallow it change anything ?