From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
10-06-2016 06:19 AM
I am currently writing a GUI that updates its components at ~ 20 Hz. More specifically, it consists of 3 image displays, 4 waveforms and a bunch of buttons and numeric indicators. The more elements I added, the more laggy the GUI got, which is especially visible in the camera image which is updating at ~ 2 Hz instead of 20 Hz.
So i stumbled upon the "Defer Panel Updates" property and hoped that would solve my problem. The GUI is built as a queued message handler and I included a message which sets "Defer Panel Updates" to true before the "Update GUI" message and another one afterwards that sets "Defer Panel Updates" to false (see attachement).
To my surprise, this doesn't change anything at all. But e.g. resizing the window such that only one image display is visible speeds that one up to normal speed (I guess LabView doesn't redraw hidden elements).
The "Defer Panel Updates" property seems to work since setting it only to True gives me a "frozen" VI as expected.
Am I missing something here or misunderstanding how this property is supposed to work? Are there other ways to speed up the GUI updates?
Thanks!
PS: I also have another VI in a SubPanel if that makes a difference. But disabling this didn't change anything.
Solved! Go to Solution.
10-06-2016 06:34 AM - edited 10-06-2016 06:40 AM
You should post your code - without it it's very difficult to see what might be causing the issue.
Have you benchmarked your Update UI case (check the time before/after the case runs) to be sure it's updating the UI that takes a long time?
What are the specs of the computer you are running on, does it have a discrete graphics card?
One obvious one to check is having overlapping controls/indicators - that can ruin GUI performance. The other is writing to lots of property nodes rather than updating via the terminal.
10-06-2016 07:06 AM
Thanks for the quick reply. I benchmarked all the update cases and their timing is <= 1 ms. The computer is two-CPU (16 cores each) work station with a dedicated Nvidia Quadro graphics card.
The updates are done maybe 50 % through local variables (for buttons that also indicate a state) and through terminals for indicators, images and waveforms.
I attached the VI, hoping that it still makes sense even if some dependencies are missing. I also removed some unsued cases to make things more clear. Bascially all cases in the "---- Updates ----" section are executed to update the GUI.
10-06-2016 07:32 AM
How big are your images?(What is the resolution?)
-You can get improvement by doing below steps:
10-06-2016 07:39 AM
Ok, so I had a quick look through your VI and I noticed the following:
- Your update of the UI occurs only when the queue times out - if there is anything else that is pushing updates to the queue, that will reset the timeout and your UI will never update. Since you said that each of your UI cases takes <1ms to run, I suspect this might be the issue. Monitor your dequeueing and see what other cases are happening that might be preventing the timeout from occurring. I can't see any real problems with the UI update cases themselves (other than perhaps the network shared variables). The use of locals isn't excessive so I can't see them being too much of a problem. It might be that one of your other cases is taking a long time and that's stopping your UI from updating - you might want to consider splitting the UI and the 'application logic' into separate loops.
- The tools palette for the images is overlaid over the image itself - this might cause you performance problems.
- You should *really* look at trying to reduce the size of your diagrams - try to keep diagrams so they only take up 1 screen of space, and if they have to scroll, make sure they only scroll in one direction!
10-06-2016 09:39 AM
@udka: The image resolution is 1280x1024.
I tried the Synchroneous Display and the Snapshot mode without any noticable difference.your suggestions without any real effect and snapshots are disabled. I didn't find "Use Smoot Updates During Drawing" in the options dialog. Currently I am using LV 2014. Using the Refresh Image method was even slower than the terminal directly.
Scroll bars and information string are already turned off.
@Sam_Sharp:
Also, running this VI does not affect the CPU and RAM usage of the PC. That is mainly caused by the server application running in the background which keeps it at ~30%.
Could it help to put things into subpanels?
10-19-2016 08:45 AM
I was just thinking that maybe my use of Shared Variables might be the culprit. I use them as Single Process SV to reduce delays.
Maybe having one GUI that accesses many of the "API SVs" forces all the VIs into on thread or something like that? Does that make any sense?
12-14-2016 10:01 AM
So I made some progress but I am really wondering how people write efficient GUIs in LabView. I suspect that my problem is that there are too many items on the user interface but can it really be that 3 camera images, 5 waveform charts and a few buttons and indicators are too much for LV?
Or is the screen resolution a factor here?
12-14-2016 10:32 AM
OK another QSM and problems.
1) Using a QSM like you are, you are forcing all of the updates to happen one after the other. One slow thing, everything slow. I would abandon the QSM and implement parallel loops and let them run in parallel rather than forced to be serialized in the QSM.
2) While it looks coll to put the palette on top of the graph charts etc, it is bad. The valius layers of the charts have to be layered and that slows down the GUI updates. Get rid of the over-lapping stuff.
3) Only update what you have to update when things change.
4) On some occations I have found (see what you reported above about a small screen updates faster when objects are hidded) in addition to the "deferFPUpdat" hidding a indicator updateing it, and then un-hide and then undefer will improve the update rate.
That is all I can think of at the moment.
Ben
12-15-2016 02:25 AM
Thank you for your input.
I didn't updload the current version of the code but I already implemented your suggestion 3) (which helped a bit). I also tried changing point 2) with no significant effect.
What helped though was to compile the GUI application into an executable.
Still, if I make an executable with only 3 camera images, the update is much smoother than if I have 3 camera images + the mentioned waveforms.
But the idea with the QSM looks interesting. I'll read up on this, thanks.
It is kind of working now, especially if I just compile different parts into their own applications. I just wonder how other people solve this or if it is related to my configuration.