The memory of a vector can only grow (at least in the SGI implementation of the STL):
vector< double > a; // a.capacity() == 0 a.resize( 10 ); // a.capacity() == 10 a.clear(); // a.capacity() == 10 a.reserve( 45 ); // a.capacity() == 45 a.reserve( 20 ); // a.capacity() == 45 a.reserve( 0 ); // a.capacity() == 45
On Linux a QPixmap is associated directly with the X Server. Therefore, you cannot manipulate a QPixmap from within a thread without crashing the programm or at least getting some error messages from Xlib, since this interferes with drawing operations from the GUI thread.
Move all QPixmap manipulations (namely drawing on it with a QPainter) into the paintEvent() and call paintEvent() asynchronously via QThread::postEvent( this, new QPaintEvent( rect(), false ) );
If you still get warnings like "Xlib: unexpected async reply" try calling QPainter::flush() a few times in between your drawing operations.
If necessary and possible, try to replace the QPixmap by QImage. An QImage is device independent and does not interfere with X.
Using the Qt library mutex allows for calling Qt methods from threads other than the event thread (qApp->lock() and qApp->unlock()). However, the Qt library mutex seems not to be recursive. Therefore, you must avoid nested calls of qApp->lock() from within a thread. Otherwise the program hangs up.
The functions lockGUI() and unlockGUI() defined in RELACSPlugin and thus availbale for the classes RePro, EventDetector, Session, and Control wrap the calls to qApp->lock() and qApp->unlock():
lockGUI(); doSomethingOnTheGUI() unlockGUI();
If possible avoid using the Qt library mutex. Posting an event is the much saver and cleaner method.