I am not sure why you would want to call replot() periodically via a timer. Did you try setAutoReplot()
I am not sure why you would want to call replot() periodically via a timer. Did you try setAutoReplot()
I do this because I do the calculations behind the data display in a worker thread, and call replot() when they are done. I use a Qt::BlockingQueuedConnection for this and have an assert() statement which guarantees that replot() is only ever getting called from the main thread.
I did try setAutoReplot(), and commented out my call to replot(), but the program crashed immediately, segfaulting in QwtPlot::drawItems. I also got this warning: "QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread".
Last edited by MattPhillips; 11th August 2014 at 14:28.
Is the calculation time dependent...
Are you doing some sort of sampling...
How about qwtsamplethread...
What is QwtSampleThread? I couldn't find that anywhere. I don't know what you mean by 'time-dependent', of course, the calculation takes some time. The timer doesn't fire until after it's complete though, so 100ms is a lower bound on the interval between repaints.
My mistake ... It's QwtSamplingThread and not QwtSampleThreadWhat is QwtSampleThread
I had a look at my post and do understand the confusion. What I wanted to know is if time is the independent variable (time vs dependent_variable)I don't know what you mean by 'time-dependent', of course, the calculation takes some time
I am still no clear why you need the help of a separate thread for calculation.
Yes, time is generally the independent variable, but what the data represent is immaterial, or have I still not understood you? Basically the program runs a numerical simulation, and the evolution of the state variables is displayed as they evolve.
I use a separate thread for calculation for the usual reason--I don't want the gui blocked while the calculations are taking place. The user needs to be able to adjust parameters, etc. as the simulation progresses.
When I'm implementing similar situations I usually use a timer in the GUI thread, that periodically checks a flag + calling replot when it has been set + clears the flag. The worker thread does nothing beside its job + setting the flag, when it has delivered something new.
Uwe
Hi Uwe,
Is the problem that I create and attach QwtPlotItems to QwtPlots within a worker thread? Do you do this? My intuition had been that calling replot from a worker thread could fail but just making the objects could be done anywhere. Otherwise, what you're saying sounds just like what I do, except that in your case the timer is in the main thread whereas in mine it's in the worker thread, which shouldn't make any difference.
I believe signal emission is always thread-safe.
Qt Code:
{ Q_OBJECT public: ~CalculationThread(); void calculation(CalculationData & data); void run(); signals: void dataChanged(); private: ... CalculationData m_data QMutex mutex; ... }; void CalculationThread::calculation(CalculationData & data) { m_data = data; if (!isRunning()) start(); ... } void CalculationThread::run() { mutex.lock(); ... //do time consuming calculations ... if(/*data changed*/) emit dataChanged(); mutex.unlock(); } { ... private slots: dataChangedCalc() } Plot::dataChangedCalc() { ... // create and attach QwtPlotItems to QwtPlots ... this->replot() } connect(&thread, SIGNAL(dataChanged()), this, SLOT(dataChangedCalc()));To copy to clipboard, switch view to plain text mode
Note: the this pointer is a pointer to a Plot
I assuming that you are creating and attaching many plotItems (that's your motivation for putting this activity in the worker thread)Is the problem that I create and attach QwtPlotItems to QwtPlots within a worker thread?
QObject and subclasses thereof are not thread safe. QwtPlot is asubclas of QObject.
Cah,
Yes, this is what it looks like I will have to try. My version of the '// create and attach QwtPlotItems to QwtPlots' part of 'dataChangedCalc' is in the worker thread; only the replot is in the mean thread. My hope is to gain some insight in advance as to whether this really should make the critical difference--see my previous post--but not knowing any other reasonable possibility I'll probably just try this in any case. Maybe you're right and it's the non-thread-safety of QwtPlot that's getting me; I only have one worker thread on the QwtPlot in question but maybe OS-generated calls to replot are causing the problem. I'll post my results in this thread when I have them.
Attaching/detaching items from a different thread is definitely not thread safe !
To make it safe you would have at least to introduce a mutex to avoid that attaching/detaching and iterating over the items in the replot operation do conflict.
For guarding the replot it is probably best to overload QwtPlot::replot(), where you do the mutex stuff before calling the base class.
Uwe
Bookmarks