VIs menu reacting too slow

[altenbach]

---

@MartinP wrote:

to display a lot of controls and indicators.

---

The term "a lot" can mean many different things to different people. and I don't think that you should use "defer panel updates". Can you give us some numbers?

• How are you writing to all these indicators and reading from these controls? Wired directly to the terminals? via local variables? via value properties? (property nodes execute synchronously and force thread switching that can get very expensive if done constantly!)
• Are you constantly setting properties, even if they remain the same?
• Do front panel object often overlap? (Overlapping objects are significantly more expensive to redraw)
• How complicated are the indicators (charts with huge histories? Graphs with huge amounts of ever-growing data and many complicated plots such as thick lines and point styles, etc.
• etc.

I think once we have a clearer picture, we can give more targeted advice. This is fixable!

[Frozen]

---

@altenbach wrote:

---

@MartinP wrote:

to display a lot of controls and indicators.

---

The term "a lot" can mean many different things to different people. and I don't think that you should use "defer panel updates". Can you give us some numbers?

---

That is strange advice 🤔

[altenbach]

---

@Frozen wrote:

---

@altenbach wrote:

---

@MartinP wrote:

to display a lot of controls and indicators.

---

The term "a lot" can mean many different things to different people. and I don't think that you should use "defer panel updates". Can you give us some numbers?

---

That is strange advice 🤔

---

It might help in the narrow scenario where tons of properties are used with each iteration (really bad idea to begin with!!!), but ultimately all indicators need to update anyway so the bulk of the work per iteration is the same. If you defer forever, the VI is not usable.

There are very few places where defer updates really help. I use it when shading table cells according to their value in a tight loop (old example).

[MartinP]

I have asked NI support for help, and forwarded the complete program to them. I'll update you what they find.

[MartinP]

With very good help from NI support, we have established that the issue is using a 4K (3840 x 2160) monitor under Windows 11 (and LV 2021).

When I changed the resolution from 4K down to 1920 x 1080, the problem is gone.

So I will have to look around for tips and tricks on this specific issue, now as we know what the problem is.

According to NI support, even the latest version of LabVIEW does not support 4K, so upgrading the LV version seems not to be an option to improve the situation. 

And I will also downgrade from Win-11 to Win-10, as it seems to be reduced from 3 sec down to 1 sec on other machines we have tried with 4K and Win-10.

Any other comments to the issue, now that we know more about the cause ?

Martin

[mcduff]

---

@MartinP wrote:

With very good help from NI support, we have established that the issue is using a 4K (3840 x 2160) monitor under Windows 11 (and LV 2021).

---

This is becoming quite common today, 4k monitors. Maybe NI should add 4k support to their roadmap.

[altenbach]

Is it just the existence of a 4K monitor or must the VI fill the entire monitor for the problem to appear?

(I really don't understand that limitation at all. Many people use multiple monitors without problem.)

[Spruce]

I had this problem with my program for years with Labview 2014 and a pair of 1920X1080 monitors. It would develop gradually the longer the program was left running by about one second extra delay per day. I periodically tried to track down the cause without success.

A couple of years ago I added a 4k third monitor which unsurprisingly didn't change anything, subsequent to this I upgraded to Labview 2024. Problem gone!

There didn't seem to be any performance impact anywhere else in the program, it was just the time taken for the submenu to drop down after clicking an item on the menu bar. The submenu items are handled by an event structure.

In the 'left running' state there's very little display updating going on. CPU usage low.

I realise this doesn't help the OP, but I've wanted to tell someone about it for ages.

[MartinP]

We have now tested the program under LabVIEW 2025 Q1, with 32 and 64 bit version of LabVIEW and the problem is still there.

I have installed a nVidia T1000 to get access to a stronger GPU, but that did not help either.

We see that when scrolling down on the LV GUI, so all objects are not visible on the screen anymore, then the problem is gone.

So it seems clear that the GUI I have created contains to many objects/controls/indicators for LabVIEW to handle in a good manner.

The problem has been escalated even one step up the knowledge chain in NI. I'll report here what feedback I get.

It would be a pity if the solution is to cut down on the LabVIEW program cause the tool simply cannot handle the high resolution good enough.

Martin

[PinguX]

---

@MartinP  a écrit :

We see that when scrolling down on the LV GUI, so all objects are not visible on the screen anymore, then the problem is gone.

---

It reminds me of an old project ... do you have any "System" controls on your GUI ? If so, could you try again after replacing them all with "Classic" controls, for example.

(The problem we had at that time was not related to Menus, but slow reaction of GUI itself)