Slow GUI Update with 80 plus spinboxes and leds

Hello,

I am currently using Qt 5.8 with visual studio 2015. I am currently running in debug mode

I am using a timer to kick off an updateGUI function call with all my GUI update calls. If I remove all the gui updates I can hit a gui refresh rate of like 500 fps.

As I add the spinboxes, led and lineseries into the mix I can get around 5-8 fps.

I have been reading and it seems all the gui updates need to be done in the main thread. All the data processing has already been pushed off to worker threads.

Are there any suggestions to getting all these updates done quickly? I'd like to at least hit 30 fps.

Hi, maybe QWidget::updatesEnabled-prop helps.

Ginsengelf

This type of a question is very hard to answer without knowing the actual code.
However, your statement:

Quote:

---

I am using a timer to kick off an updateGUI function call with all my GUI update calls.

---

is very suspicious.
What is suspicious is the fact you need it, or that you think you need it - odds are this is a symptom of a design problem, again, what the problem actually may be is really impossible to tell with out knowing the code or at least having more information about it.

Below is an example of my code structure.

I tried at first putting a 10 ms delay in the timer, but my device can generate 1000s of data packets each second. So, I just grab the latest one and display when I do a get.

Code:

---

CommGUI::CommGUI(Comm *drwg, QWidget *parent)
	: QMainWindow(parent)
{
	ui.setupUi(this);
 
	QTimer *refreshTimer = new QTimer(this);
	refreshTimer->start(0);	
 
	QObject::connect(refreshTimer, SIGNAL(timeout()), this, SLOT(UpdateGUI()));		
}

---

Code:

---

void CommGUI::UpdateGUI()
{
	// Get Message from device
        // put data into map
        // this runs fast and is running in a separate thread
 
       // example spinbox update
       // 80 of these
       ui.spinbox->setValue(map.value);
 
       return;
}

---

Refreshing / updating ~ 80 widgets (like spinbox / led) should be fairly quick.

Here are couple of things you can consider to check/explore.

1. Make sure you each widget is updated only once in a cycle.
2. It would be better to get the changed data map, rather than all data map from worker thread.
3. It would be better not to connect any slots to value changed signals of spinbox directly.
4. Measure the time spent inside UpdateGUI() and measure the time to get the data from back ground thread separately, this could give you some surprising numbers.

Quote:

---

Santosh Reddy
Re: Slow GUI Update with 80 plus spinboxes and leds

Refreshing / updating ~ 80 widgets (like spinbox / led) should be fairly quick.

Here are couple of things you can consider to check/explore.

1. Make sure you each widget is updated only once in a cycle.
2. It would be better to get the changed data map, rather than all data map from worker thread.
3. It would be better not to connect any slots to value changed signals of spinbox directly.
4. Measure the time spent inside UpdateGUI() and measure the time to get the data from back ground thread separately, this could give you some surprising numbers.

---

I did find that I had some widgets being updated twice. That slowed it up some for sure.

I timed the data grabs and they were very quick in vs, under a 1ms. I plan to make this faster in the future and have the work thread already populate a map and not do a data grab. I have reasons to do this other than speed.

I don't have any slots directly to the spinboxes.

But, now I added back in a lineseries->replace call and it has also caused a slow up. It is much better than when I was using the append function.

Is there a fast way to plot a lineseries or is there a better library to use. I do have a video card an nvidia card with opengl available too.

Thanks you so much for the help so far.

Did you follow on anda's suggestion Nr.4?
I too would start with that.
Then you'd know where you lose your time - if its primarily in getting the data or the UI update and then you can look for the best strategy how to fix the issue - or may be even first to try and understand why it is happening.
How does the "put data into map" code looks like?
That too could be a good candidate for being slow if done inefficient.
You did write this part is happening fast, but I wonder still.

One thing could also be the very fact you are using a thread (or how you use it).
If you are using mutexes when writing/reading the data to the map, depending on how you implement it and the interplay of frequency between writing/reading data to/from the map both by the worker thread and the UI they might be stepping on each others toes.

I got 60 fps now in release mode even with a 10 ms timer for my timer.

I ended up using some bits and pieces from the example, OpenGL Accelerated Series Example. I mainly used the opengl flag and using the replace call.