ideas for speeding up front panel

[bmishoe]

Without boring you w/ the detail, I have a project that has worked fine that historically would display 14 registers at a time on the front panel.  Recently I received a request to try and condense these registers dynamically based on how many fields are in the regs (i.e. is the reg 16 one-bit fields, or one 16-bit number), allowing the user to see more registers at once.

I was able to do this, and it works, but now the front panel responds slowly.  Specifically, when I click the up/down arrows of the numeric controls, it can take nearly 1 second to respond (i.e. if I click 'up' 5x in a row, I will see it slowly count up to 5 over a period of 2-3 seconds).  I have done some experimenting and determined that this doesn't happen if I only have a few controls/indicators on my front panel (i.e. it responds quickly), which leads me to conclude that as the number of controls/indicators increases, there comes a point where it will start to noticeably delay.

I use event structures to determine if a control changed, and a queue (with a 100ms timeout) for the values received from the telnet connection to the card that will populate the indicators (however, right now I'm in a 'test' mode whereby there's no actual telnet connection to anything).

I have done some researching and it seems that the main recommendation for solving this problem (apart from reducing the number of controls) would be to use the defer FP updates property...but in my case, I don't think that's playing a role here, because as I mentioned earlier, I'm not connected to a card.  in other words, the only 'updates' that are occurring on the front panel are the ones generated by me with mouse clicks.

So I guess my question is, is this too many ctrls/indicators for a front panel, or is there some other tricks I can try?  The same thing happens when I create an exe, FWIW.

[GerdW]

Hi bmishoe,

so there is a problem with your VI - and we should (help to) solve this by looking at an image of a part of it's frontpanel?

Please attach the VI…

I don't think there are "too many" controls/indicators. (IMHO the GUI just "doesn't look good"…)

[aeastet]

Can you post your code. It would make it easier to see if it is a front panel thing or a code execution thing.

[bmishoe]

I didn't attach it because:

1. what you see is made up of literally about 40 different VIs, including VI Scripting to generate all the controls and indicators from a text file.

2. I wanted to get a feel of whether or not I have too many controls (which can be gleaned from a picture) - sounds like you think I do not have enough to cause a delay, so thank you for that input.

[bmishoe]

I'll tell you what, I'll investigate some more and try and determine if there's one module in particular that is causing the delay, and then if so I'll definitely post that.  Thanks for the willingness to help, stay tuned.

[dkfire]

How are you updating/reading from all these control/indicators ?

[paul.r]

Updating the UI is slow, however I wouldn't expect a 1 second delay unless your UI is processing a lot of data updates/updating a lot of indicators, in addition to responding to your input. By a lot, I am talking about hundreds or thousands of other UI updates/second. Doesn't sound like that is the case, so the problem is most likely elsewhere.

That said, you should still probably try and optimize your UI code if you have a lot stuff in the UI. Are you updating indicators even if they aren't visible? (Only update the indicators that are actively being shown on the tab control) Have you looked into using subpanels?

[stevem181]

2. I wanted to get a feel of whether or not I have too many controls (which can be gleaned from a picture) - sounds like you think I do not have enough to cause a delay, so thank you for that input.

You haven't said "how" you are updating the controls. The Value Property Nodes are slow, Value signalling is even slower.

Have you looked at the CPU usage using Task Manager?

The UI thread is usually indicated by the core with the highest usage.

I try to keep this number below 25% max even on my old i5 CPU.

And this is with hundreds of controls and indicators.

steve

[Yamaeda]

Are you using many property nodes and are you hiding/showing items every update, that'll slow down things a lot. Especially visibility can gain speed be wiring the error wire so only 1 updates at a time. I had a similar problem in a program where i had a Tab control with 2 big Clusters and when i just changed Visibility it took 0.5-1s to change, but when wiring them with the error wire it dropped to <0.1, i guess it got stuck in some dirty/refresh loop for each cluster element instead of hiding the full cluster, then the other.

/Y

[bmishoe]

I'm back on this this morning...I've attached a picture of how I'm updating these indicators.  As new values are received from the TCP connection (again, not active at the moment), they're stuffed into a queue.  Here, I pop values from that queue and then light the indicator(s) accordingly based on the address contained in the received data.  Everything you see in the attached was generated by a VI script (which is why it's a little messy).