LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Laggy GUI - defer updates?

Solved!
Go to solution

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.

0 Kudos
Message 1 of 18
(6,164 Views)

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.


LabVIEW Champion, CLA, CLED, CTD
(blog)
0 Kudos
Message 2 of 18
(6,148 Views)

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.

0 Kudos
Message 3 of 18
(6,130 Views)

How big are your images?(What is the resolution?)

-You can get improvement by doing below steps:

  • You can request that LabVIEW update the screen each time data is wired to the image display control by right-clicking the control and selecting Advanced»Synchronous Display from the shortcut menu.
  • You also can use the Refresh Image method with the image display control to request an updated display of the image that is currently wired into the control. 
  • Additionally, you can remove the checkmark from the Use smooth updates during drawing checkbox on the Front Panel page of the Options dialog box to increase the update rate. Note that this change might introduce flicker in the image.
  • You also can improve the update rate by doing the following:
    • Reduce the size of the image display control.
    • Use the classic image display control, which has no 3D parts.
    • Hide the image display control scroll bars.
    • Hide the image display control image information string.
  • Enabling the Snapshot Mode may reduce the speed of your application because the control makes a copy of the image. Enable this property when you want to display a snapshot of the image in time. Disable this property when you need to display results quickly, such as during a grab acquisition. The Snapshot Mode property is disabled by default, make sure it is disabled.
Thanks
uday
0 Kudos
Message 4 of 18
(6,114 Views)

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!


LabVIEW Champion, CLA, CLED, CTD
(blog)
0 Kudos
Message 5 of 18
(6,109 Views)

@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:

  • I checked the timing of the GUI update (the frequency of how often the timeout case happens). Interestingly it is running every 51 ms when I do not send the "Defer Panel Updates" message. If I send these as well, it drops to 150 ms. So using the "Defer Panel Updates" makes everything even slower (strange?). Otherwise the 51 ms are the expected value. And there are no other unexpected messages appearing.
  • Moving the tools palette away doesn't change anything.
  • I would love to decrease the diagram size and are open for tips on this. But in fact the code there is the bare minimum to relay GUI user actions to the API of the server running in the background and to display data coming from the server. The only way I see to reduce the size would be using subpanels which makes it hard to play with the way things are organized on the user interface. When coding for LabView, I heavily rely on the automatic diagram clean up which is quite inefficient for case structures with many cases (introduces large empty spaces). I think this is why the diagram looks huge. If you have any other recommendations, I am happy to hear them.

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?

 

 

0 Kudos
Message 6 of 18
(6,077 Views)

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?

0 Kudos
Message 7 of 18
(5,960 Views)

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?

0 Kudos
Message 8 of 18
(5,754 Views)

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

 

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 9 of 18
(5,747 Views)

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.

0 Kudos
Message 10 of 18
(5,718 Views)