@texasRanger Why do you think you need an additional event loop? From your description I don't see any need for it. If file is changed you will get a signal from file watcher. You just need to make sure parsing of that file does not take too long.
Thanks for answering.
Basically, I am separating rendering and updating to have fixed-timestep updating (for physics etc) as well as as-fast-as-possible rendering with time interpolation. (Heavily heavily inspired from Gaffer on Games article)
My code looks as follows (only slightly simplified):
... within my OpenGLContext
const double delta = 1.0 / fixedUpdatesPerSecond;
auto time = QDateTime::currentMSecsSinceEpoch();
double accumulated = 0.0;
while (! this->terminate)
auto newTime = QDateTime::currentMSecsSinceEpoch();
double frameExecution = tdiff(time, newTime);
time = newTime;
accumulated += frameExecution;
while (accumulated >= delta)
// Handle user input / system polling
//However, since Qt has event driven polling, let's just call processEvents and then handle any input events by putting their results into a map.
// Update our states
accumulated -= delta;
this->render(accumulated / delta);
In the same class, I have updateState and render:
void MyGL::updateState(float delta)
//... Bunch of commented-out code to make sure base loop works first
cam->translateAlongForward(delta * 3.0);
void MyGL::render(float aheadAlphaPercent)
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
// a lot of other drawing stuff
I know that my rendering code itself works because I initially tested it by just using a QTimer.
Instead, I now do the following:
QApplication a(argc, argv);
... MainWindow::start (MainWindow is QMainWindow subclass)...
uiElements->glWindow->gameLoop(); //glWindow is subclass of OpenGLContext
As you can see, I tried to avoid calling Qt's blocking event loop in QApplication::exec, but am still polling events. However, this doesn't work properly, as described in my first post.
It seemed to be the fault of the default QSeries implementation... Series.append() apparently emit a couple of signals and resize the inner vector which contain the QPoints. This combined to a O(kn²) loop totally messes up the main event loop.
It was "as easy" as refractoring the code so the thread builds up a QVector of QPoints, then signals each vector to the chart and it calls to series.replace() instead of append(), that is actually faster and lighter.
great that you were able to fix it yourself, and I learned something new and important about QCharts thank you ;-)
I was about to give up after trying the moveToThread way without success, but I was lucky enough to get the solution after finding this.
So, not a matter of Qthreads after all.. Now I'm wondering whether refracting the code to create a dedicated event-loop was worth it or not.
If an actual worker class is now replacing your infinite while loop, that you posted in the op, than yes it is, definitely!
I'm having a new problem when I move a second QTcpSocket inside the thread.
Everything seems to work fine but the thread is crashing (segmentation fault) after deletion (after receiving the destroyed signal). It seems to be an desallocation issue... I couldn't manage to figure out the problem yesterday and today...
I'm going to write a easier example of my architecture and open a new post.
I have found the problem. It was a blocking ftp download which did not finish because of broken communication. Pushing the download to a separate thread unveiled the problem respectively made it tracable.