Laggy GUI - defer updates?

[ehrlich]

Ah and one more point: I now switched to use SubPanels for grouped elements so I basically have only one case in the QSM which updates the GUI for each of these groups. But since they all run in their own SubPanels, I don't know how the top level GUI is updated. Probably whenever a SubPanel is redrawn.

[Yamaeda]

---

@ehrlich wrote:

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

---

If you check the Defer panel update help, you'll see that turning it on or off forces a redraw, so if you do it for each update you'll get extra redraws.

[Ben]

---

@Yamaeda wrote:

---

...

---

If you check the Defer panel update help, you'll see that turning it on or off forces a redraw, so if you do it for each update you'll get extra redraws.

---

That is an excellent point Yamaeda !

The deferFPUpdat and all of he other stuff is what I turn to after I have ruled out all other issues and am convinced the GUI update is the bottle kneck.

If progress is made with other changes, go back and toss the "DeferFpUdat" and such because the DeferFPUdat could actually be incireasing the demand on the GUI updates.

Ben

[ehrlich]

In the current version of my GUI, I don't use the defer panel updates node anymore, since it effectively made everything much slower. Probably due to what you mentioned, that it forces a redraw of everything.

[ehrlich · Accepted solution]

I got it to a state where I am happy with performance right now and the way to get there was a mix of was was mentioned in this thread:

• The GUI is now split up into subpanels and each of them controls only a few GUI elements. This also reduces block diagram complexity and size.
• The GUI is running in its own process and communicates with the data processing app via networked shared variables. This also makes it very easy to build the GUI and have it as an executable.
• The code is now only updating elements whose value has actually changed.
• The tools palette for the images is not overlaid over the image anymore. In a first test, this didn't have any effect but for fine tuning after implementing the previous points this definitly improved things!

Thank you everybody for your input!

[WhrlpoolMind]

This is a great progress, thank you for sharing it.

I also experienced that if large data has to be displayed and rescaled on the UI, it can cause lags. To reduce such lags I rescaled the data before sending it to the UI.

[ehrlich]

What exactly do you mean by rescaling in this context? Reducing resolution of images? What did you do for waveforms?

[WhrlpoolMind]

If the data to be plotted has more points than the length of the actual plot area of the graph in pixels, the GUI thread has to rescale it. The more data points have to be plotted, the more calculations have to be done by the GUI thread.

With the large data I had to work (e. g. multiple minutes of data measured on 8 channels with DBL representation and 1-100 kHz sampling rate) it did not matter whether the 8 waveforms were plotted in 8 Waveform Graphs in the same Front Panel, or they were plotted in 8 Waveform Graphs in multiple subpanels, or in one XY Graph, the overhead of plotting was about the same time.

The solution for that problem was that I rescaled the data to be plotted to the same point number as the length of the plot area of Graphs in pixels right after recieving it, and only this small amount of data was sent tu the Graphs, so the calculation overhead of plotting (in the GUI thread) was minimized.