2

I have a QT application that allows a user to define a list of models. Each model defined has a fairly complex widget class that is created. Currently this is all being done in the main (GUI) thread. The program works fine for normal use, but I tried to stress test it by creating 200 to 1000 models and the creation of the GUI took a VERY long time (20 seconds to many minutes).

I tried a couple attempts at threading out the work using QtConcurrent::run, but the program always complained because "Widgets must be created in the GUI thread."

I found this answer on SO: How do I create a Window in different QT threads?. But this doesn't seem to be doing much in the new thread except telling the main thread to create a new widget. This does not distribute the workload, as far as I can tell.

With all of that, I have a couple direct questions:

1) Is there a better design (faster performance) than looping through my list of models and serially creating each widget?

2) If this process is possible to be multithreaded, can someone point me in the direction of a simple example?

Community
  • 1
  • 1
Snowman6286
  • 150
  • 6
  • 2
    Better design would be to create the widget when you need it... How many widgets you actually have visible at one time? And what models so you actually mean? Subclasses of *QAbstractItemModel* or what? – hyde Dec 04 '13 at 19:58
  • Thanks for the input! Only one widget is visible at a time. There is a tree view that can be used to select which widget you want displayed at a given time. Only displaying them when needed might work, but I would be worried about dynamically loading them if someone were to scroll through all the models at once. – Snowman6286 Dec 04 '13 at 20:30

1 Answers1

2

There really is no way to put widget stuff to other threads. OpenGL rendering or some data processing for a widget to show when ready, stuff like that can easily use other thread, but not the actual widgets.

Better design would be to create the widget when you need it. Or just have one widget and update the data it displays (unless widgets for different items are actually different).

If you are worried about performance when scrolling, then one solution to that is to switch widget only after current one has been visible for some minimum time (say, 500ms if user keeps scrolling, or 200ms after last scroll event, some logic like that) note that this is not delay for reacting to user selection, this is delay after selection and visible widget change, so if user just changes to next item, GUI is updated immediately. But in scrolling the widget is not updated for every item briefly selected, and things don't slow down. Use QTimer or two to send signal when widget should be updated.

hyde
  • 60,639
  • 21
  • 115
  • 176
  • Thanks for the design idea. I will give it a try. – Snowman6286 Dec 05 '13 at 13:05
  • By only initializing the display part of the widgets as needed I am able to launch 1000+ models with a small impact to start-up time. I have yet to implement the scrolling logic, but this looks very promising. Thank you again. – Snowman6286 Dec 05 '13 at 14:50