Freezing issue caused by socket and UI updates in the thread and main thread
-
I use UDP socket. This socket runs on a separate thread.
I receive graphical data through the socket. I then plot the incoming data on a graph.
QTimer m_processer; QElapsedTimer m_sender; double m_sendTime = 5; double m_parseTime = 1; UdpSocket::UdpSocket(QObject *parent) : QObject{parent} { connect(&m_processer, &QTimer::timeout, this, &UdpSocket::processIncomingDatagram); m_processer.start(m_parseTime); m_sender.start(); } void UdpSocket::readyRead() { while(m_socket->hasPendingDatagrams()){ QNetworkDatagram datagram = m_socket->receiveDatagram(); m_buffer.append(datagram.data()); } } void UdpSocket::processIncomingDatagram() { while (true) { // Something check here parseData(frame); m_buffer.remove(0, 8 + static_cast<int>(len)); } } // MySocket takes inheritance from UdpSocket void MySocket::parseData(QByteArray data) { // Parsing here m_received += count; if(m_received >= size){ m_received = 0; qint64 elapsed = m_sender.elapsed(); if(elapsed >= m_sendTime){ emit sendData(. . .); m_sender.restart(); } qDebug() << "RECEIVE :" << size << elapsed; } } void MainWindow::sendData(. . .) { if (m_processing) return; m_processing= true; if(m_qwt){ m_qwt->compute(. . .); m_qwt->render(); } m_processing = false; }I mentioned earlier that the MySocket is running in a different thread.
RECEIVE : 131072 6
RECEIVE : 131072 6
RECEIVE : 131072 5
RECEIVE : 131072 6
RECEIVE : 131072 6
RECEIVE : 131072 7
RECEIVE : 131072 4
RECEIVE : 131072 10
RECEIVE : 131072 6
RECEIVE : 131072 4
RECEIVE : 131072 10
RECEIVE : 131072 4I am able to get an output like this
In addition, the QWT update on the main window takes a maximum of 5 ms
What should I do? What do you recommend? How can I process data that’s coming in this fast?
-
Hi,
I would:
- Remove that infinite loop -> Qt is event driven so grab the data when it arrives then trigger the processing
- If the data is "too fast" then there's no sense in trying to show it all the time, your users won't be able to see all these changes (it's like trying to show a billion points -> useless). Batch the updates at a rate that is useful.
Also, there's no need to subclass QUdpSocket, you just use it thus avoid subclassing in this case.
-
Hi,
I would:
- Remove that infinite loop -> Qt is event driven so grab the data when it arrives then trigger the processing
- If the data is "too fast" then there's no sense in trying to show it all the time, your users won't be able to see all these changes (it's like trying to show a billion points -> useless). Batch the updates at a rate that is useful.
Also, there's no need to subclass QUdpSocket, you just use it thus avoid subclassing in this case.
@SGaist said in Freezing issue caused by socket and UI updates in the thread and main thread:
Remove that infinite loop -> Qt is event driven so grab the data when it arrives then trigger the processing
That for check crc
void UdpSocket::processIncomingDatagram() { static const QByteArray magic("\x55\xAA\x55\xAA", 4); while (true) { const int pos = m_buffer.indexOf(magic); if (pos < 0) { m_buffer.clear(); break; } if (pos > 0) m_buffer.remove(0, pos); if (m_buffer.size() < 8) break; const quint32 len = qFromBigEndian<quint32>(reinterpret_cast<const uchar*>(m_buffer.constData() + 4)); if (m_buffer.size() < 8 + static_cast<int>(len)) break; const QByteArray frame = m_buffer.left(8 + static_cast<int>(len)); if (!calculateCrc(frame)) { m_buffer.remove(0, 1); continue; } parseData(frame); m_buffer.remove(0, 8 + static_cast<int>(len)); } }@SGaist said in Freezing issue caused by socket and UI updates in the thread and main thread:
If the data is "too fast" then there's no sense in trying to show it all the time, your users won't be able to see all these changes (it's like trying to show a billion points -> useless). Batch the updates at a rate that is useful.
I also use decimation for points.
@SGaist said in Freezing issue caused by socket and UI updates in the thread and main thread:
Also, there's no need to subclass QUdpSocket, you just use it thus avoid subclassing in this case.
no no no my UdpSocket class is QObject
-
Sorry for the confusion, I misread the UdpSocket content.
That said, how many times per second are you triggering an update to your graph ?
Did you check the Qwt Oscilloscope example ? -
Hi @SGaist , I update plot approximately 40-60 times, It can be changeable cause of calculate time.
Actually, it seemed a little complicated to me. I transfer the data into a QVector<float> and then replot it.
void MyPlot::addFrame(const QVector<float> &data) { . . . // x and y : QVector<float> // Basicly like that but more calculating I do for(int i = 0; i < data.size(); i++){ float x_val = i; x.append(x_val); float y_val = data[i] y.append(y_val); } } void MyPlot::render() { if (!plot || !curve) return; const int count = x.size(); curve->setRawSamples(x.data(), y.data(), count); plot->replot(); }What do you think ? Example code way better ? It use lock and unlock like somethings. I do not know.
-
Hi @SGaist , I update plot approximately 40-60 times, It can be changeable cause of calculate time.
Actually, it seemed a little complicated to me. I transfer the data into a QVector<float> and then replot it.
void MyPlot::addFrame(const QVector<float> &data) { . . . // x and y : QVector<float> // Basicly like that but more calculating I do for(int i = 0; i < data.size(); i++){ float x_val = i; x.append(x_val); float y_val = data[i] y.append(y_val); } } void MyPlot::render() { if (!plot || !curve) return; const int count = x.size(); curve->setRawSamples(x.data(), y.data(), count); plot->replot(); }What do you think ? Example code way better ? It use lock and unlock like somethings. I do not know.
@Joe-von-Habsburg said in Freezing issue caused by socket and UI updates in the thread and main thread:
Hi @SGaist , I update plot approximately 40-60 times, It can be changeable cause of calculate time.
50-60 times per second ?
-
yes, receive and calculation 30-40ms, I update plot
50-60Hz30Hz rate -
60Hz would require 16ms. With 30-40ms you only need to update the plot with a 25-30Hz rate.
-
@SimonSchroeder opps sorry,
As I mentioned, it can vary depending on the data acquisition and processing operations. It’s running at 30–60 Hz for me. I wish I could speed it up even more, but the amount of data I’m collecting is really large, and because of that, my processing time is increasing.
-
How are you processing things currently ?
Using multiple threads ? Involving the GPU ?
What kind of processing are you doing ?