qt - setText outside of paint events not ok?

Question

Under Qt 4.7.1, Qt Creator 2.1.0, OS X 10.6.8:

I have a QLabel in the mainwindow ui, which uses Courier New / 13, with room for four lines of text.

I create four lines of text, considerably shorter than the label is horizontally, of the general format:

"my text\r\n"

I filter the text before sending it along. The only characters in the cstring will be 0x0D, 0x0A, 0x20 (space) and from there up to lower case z (0x7A') and of course the terminating zero. No other control characters - if they are received from the source, I replace them with '*'

I send the four lines of text to the QLabel as a single zero-terminated cstring via setText()

I sometimes do this at a fairly high rate, several times a second at least -- this is RDBS data from an FM station so it changes in real time:

qDebug() << rbl;                    // data keeps coming to console
ui->fourLineLabel->setText(rbl);    // add this, display soon stops updating

This works. For a while. Then the display stops updating. This is the area at issue:

_{(source: fyngyrz.com)}

If I leave everything else in, but take out the setText(), the problem does not occur.

I know that for some things, Qt wants painting to be done within a paint event. Is this also true of a setText() ?

Reading the docs on qt widgets, it says that widgets do their own painting within their own paint event... but the behavior here is very similar to the kind of malfappery that goes on when one actually tries to use a painter outside of a paint event. And it's definitely related to that setText(), so... mumble.

As I write this, the application has been running for hours without any display lockup, outputting the same text to the console via qDebug(). It takes about 5 minutes for the problem to occur if I uncomment the setText(). It's 100% repeatable.

Is there something I should be doing that I'm not doing, paint-wise or similar?

Thanks for any assistance.

Answer 1

In general you should not update Qt controls from non UI thread, only a small amount of things is allowed to do regarding a painting in non UI thread - http://doc.qt.io/qt-4.8/threads-modules.html

If you need to update UI from non UI thread - use signals and slots (QueuedConnection or BlockingQueuedConnection connections, though make sure to not create deadlock with BlockingQueuedConnection). Or if you don't want to create additional signals and slots for some easy update - use invokeMethod (it can even return value and if you use it with BlockingQueuedConnection connection type, your thread will wait until UI is updated).

And a general advice - if you have a possibility - make one call for bulk of updates to UI instead of few small calls.

Answer 2

It is always advised that the GUI thread interfaces with all other objects through the signal-slot mechanism. In fact, no direct calls from and to the main thread are to be made. In that manner the GUI will be responsive, and we don't end up waiting for it to come back. Certainly polling solutions are not ideal, and should be avoided as they end up using cup resources without reason.

If one is using only QThread type threads then updating the GUI should be done by using the signal-slot mechanism. When events of data presented need to be serialized using the Qt::QueuedConnection is sufficient. In your case that is true.

If not using that , then signals may not be processed in the sequence emitted. Qt::BlockingQueuedConnection should be used only when we want to restrict the caller continue from processing before the slot on the receiver has completed. This is very rarely the case for processing that happens on the GUI thread.

Special care has to be taken when we want to connect from a non-qt thread, e.g. An std thread, because the objects created e.g. in a native thread will not be known on the receiver end.

One way to update the ui from a non-ui thread is to serialize and copy your messages. Do the following (works even for non-QThreads e.g. boost::thread ):

• Setup a singleton QObject that provides public methods to force-emit signals containing the data that you want to send ,e.g. a singleton
• Setup slots in objects that only accept arguments by value
• Connect the signals to the slots in an object within the ui-thread

• Connections must be Qt::QueuedConnection

  class timer : public QObject
  { 
  Q_OBJECT
  //... write a singleton here
  
  std::mutex mut;
  
  public signals:
  signal_tic(QString const );
  
  public: 
  void force_emit_tic(QString const s )
  {
     std::lock_guard<std::mutex> l(mut);
     emit signal_tic(s);
  }
  
  timer & ref() 
  {
    static timer This;
    return This;
  }
  private:
  timer(){}
  };
  
  // in a main thread object setup this connection
  
  connect(&timer::ref(),SIGNAL(signal_tic(Qstring 
  const)),this,SLOT(slot_accept_tic(QString const ), Qt::QueuedConnection)
  
  // In any other thread
  timer::ref()::force_emit_tic( string_when_this_happened )
  

Calling directly the singleton force-emit method results in the desired behaviour. (ofcourse objects must be properly copiable for this to work)

The reason for sending by value is that if you pass a const reference to temporary residing in another thread it's lifetime is not guaranteed. Furthermore, you need to take care of serializing the messages to the ui-thread before they actually arrive or you will eventually receive one of either incosistent data or a SIGSEGV. Qt::QueuedConnection guarantees that connections are serialized only within the memory space known to QThreads.