QtConcurrent run with a never ending while loop leads to high CPU usage

nagesh

void Controller::play()
{
    while(m_isPlaying)
    {
         // get frames from file
         // update GUI with frame
         emit showFrameOnWidget(read());                 
         // update timestamp label
         emit updateTimestamp(m_timestamp);
    } 
}

As play() function is part of while loop without sleep how do you ensure fps?
At present it looks like as soon as data read from file is ready signal is emitted, which is causing high cpu usage.
Do a comparison of how much time Same file taking to play in VLC and your application?

jeremy_k

@nagesh said in QtConcurrent run with a never ending while loop leads to high CPU usage:

As play() function is part of while loop without sleep how do you ensure fps?

I missed that the source is a file and not a camera producing frames at a fixed rate.

!

A timer or blocking IO of some sort is going to be necessary if the goal isn't to be gated by the io, cpu, or memory capacity of the system. Sleeping a fixed interval is a problematic solution because it fails to take into account variability in available capacity. Either set a high precision timer for the desired frame rate, or cause the processing thread to block between each frame while the ui thread deals with it.

edit: Or use an interface such as QVideoFilterRunnable that is invoked in a manner suitable for playback.

MarKS

@nagesh I think you misunderstood my question. I know to ensure FPS and deal with high CPU usage, I need some way to slow down the thread. I asked for a better way to deal with it rather than using thread sleep which in my opinion, not a good design.

MarKS

@jeremy_k You're right. So, I made a comparison between using a QtConcurrent::run() and QTimer. Here are my observations:

QtConcurrent::run() is very fast. So I used QThread::msleep(mstime). mstime is calculated from the native fps. For e.g. 30 fps native needs 33 mstime between the frames. CPU Usage: ~40-45%
Calling play() using QTimer->start(mstime) where mstime is 33 ms leads to CPU usage to ~30-35%

It looks like QTimer gives GUI a bit of breather to process events but runs slower than 30 fps playback speed. Whereas, QtConcurrent::run() achieves 30 fps playback speed but drives higher CPU usage.

It means QTimer sleep interval doesn't guarantee accuracy even though I am using Qt::PreciseTimer. Please correct me if I am wrong. I do not actually understand how the QTimer functions.

But for now, I am stuck between 2 choices.

nagesh

@MarKS Qt::PreciseTimer guarantees accuracy up to 1msec, but in that slot what operation is performed that matters.

Calling play() using QTimer->start(mstime) where mstime is 33 ms leads to CPU usage to ~30-35%

Does this timer is running in GUI/main context?

try to create the worker object having Signal/slot and move it to thread context using movetothread..

This might reduce the CPU usage

Christian Ehrlicher

@MarKS said in QtConcurrent run with a never ending while loop leads to high CPU usage:

And yes each signal has its own slot.

This was not what @SGaist said - he said you should not emit three different signals with the same data but only one.

MarKS

@Christian-Ehrlicher I understood. What I meant was 3 different signals are emitted with 3 different channels to 3 different slots. I put the same channel just as an example.

MarKS

@nagesh yes the timer is created in GUI thread. Never tried QTimer in another thread. Will search how to do that. But if you have any pointers that would be helpful.

nagesh

@MarKS I would suggest first example provided here
https://doc.qt.io/qt-5/qthread.html

You can use worker objects by moving them to the thread using QObject::moveToThread().

In worker object create timer.

kshegunov

What is DataBuffer? And how do you render the data in the GUI thread?