[QT4] Display continuously changing with time (QThread and QTimer ?)

[Corran]

I have a canvas on which I am drawing a set of points. They are supposed to move as a function of time (sort of like a series of planets moving under gravity). I want the canvas to be continuously refreshed with the new positions of the points.

I guess I need to somehow combine a QTimer and a QThread (to avoid a never ending loop) but I'm not sure how to combine them. Should I start a thread and put a timer in it which every so often calculates the new positions and updates the view or maybe I am supposed to start a timer loop which starts a new thread every time the calculation needs to be made?

Any help would be greatly appreciated.

[jpn]

How "heavy" is that calculation process? I mean, are you sure you need multi-threading at all? ;)
Maybe you could test it first with a simple way? Setup a timer calling your custom slot which handles the calculation and calls update() for the canvas view..

[wysota]

I'll ask a simple question -- do you have more than one CPU in your machine?

[Corran]

Well it's a calculation that, if performing 30000 iterations, can take up to 5 minutes. After each iteration the canvas is repainted. However, while the calculation is taking place, the whole program is unresponsive and the only way to stop it is to either wait for the calculation to finish or kill it. Furthermore, it would be nice to be able to stop the calculation at any point and restore control over the GUI.

Both the unresponsiveness and the need for stopping it at any point suggested to me using a QThread as I believe it can be sent a signal to stop it.

It is no longer necessary to have it working on a fixed timebase, the speed at which the calculation is conducted is sufficient.

And no, I don't have more than one CPU. Is that needed for multi-threading? If it is I probably look a little silly now :D.

[wysota]

And no, I don't have more than one CPU. Is that needed for multi-threading? If it is I probably look a little silly now :D.

It's not needed, but if you have a single CPU then having multiple threads will only cause a slown down instead of speed improvement.

You should divide your iterations into smaller steps and either use a timer with timeout of 0 or use QApplication :: processEvents().

[yop]

Well it's a calculation that, if performing 30000 iterations, can take up to 5 minutes. After each iteration the canvas is repainted. However, while the calculation is taking place, the whole program is unresponsive and the only way to stop it is to either wait for the calculation to finish or kill it. Furthermore, it would be nice to be able to stop the calculation at any point and restore control over the GUI.I 've been there, I could keep the gui non responcive for up to 15 minutes depending on user input. I read anything I could find on optimizations and managed to fix my algorithm an optimize it first. Iterarations (and mostly nested ones) are hungry ;).


Both the unresponsiveness and the need for stopping it at any point suggested to me using a QThread as I believe it can be sent a signal to stop it.
Could work but it 'll take more work than just inserting some QApplication :: processEvents() in your code to make the gui responsive.

[Corran]

Fortunately I only needed the GUI responsive enough to be able to click a 'Stop' button and so putting a processEvents() and a check for the button press in the loop served my needs.

Thanks for all your help.