Responsiveness of Qt GUI

Question

I'm doing a lot of activity in the Qt GUI thread on application startup (creating/preallocating and hiding literally over a thousand widgets, mostly as a runtime/initialization tradeoff, it's an embedded system that needs to stay responsive during it's operation).

The goal of a responsive operation has been met - but now I have a challenge of making the initialization more responsive. Threading the initialization off to the worker thread is not an option - most of the CPU load comes from within calls to QtGui, and those need to take place in the main thread.

So, I wonder if there is an option to yield the control over to the app to handle all the other events? do the redraws, etc?

Answer 1

More cleanly, without needing to sprinkle your code with processEvents() calls: implement your creating/preallocating as slot(s). Make it one slot with encapsulated state machine (knowing what to do next), or do more slots, or delegate to some classes with common interface, depends on your design and taste. Upon each finished call to the slot, post the call to yourself again as queued connection.

slots: void makeWidget();
signals: void widgetMade();
...
connect(this,SIGNAL(widgetMade()),this,SLOT(makeWidget()),Qt::QueuedConnection);

That way, your widget creation will be queued equally to other GUI activity. The explicit 5th parameter qualifier is necessary, default Qt::AutoConnection would be resolved to Qt::DirectConnection because you are in the same thread. As a bonus, you could actually do a non-blocking progress bar of your initialization, given that you know how many widgets are to be initialized.

Answer 2

Seems that my GoogleFu had abandoned me for a while:

qApp->processEvents()

This processes all the outstanding GUI events - just calling it often enough solves the problem.