Creating widgets in "another" thread...

[jsulm]

@Dariusz said in Creating widgets in "another" thread...:

how can I call main thread from my sub thread

Using signals/slots.
But you should not create the widgets in another thread than main thread!
Why do you want to do so? I don't see the point. This another thread can do what it is supposed to do and then notify the main thread via signal and main thread then can create the widget.

[Dariusz]

Its the current app design I'm afraid.

When app starts it creates all attribute widget containers, but cant initialize them untill an actuall node with data is created. Now when user click on node (in treeView) then I emit signal to my worker thread to handle selection, this has to process data / display it. At this point the attribute widget sees data for 1st time and has to finish initialization... Its a bit.. "backward" I'm thinking of remaking it.

Atm I did

                    QMetaObject::invokeMethod(qApp, [&, sType, node, name = node->getIcName()]() {initializeWidget();populateWidget();},Qt::QueuedConnection);

To push it back to main thread. Even tho its still "slow" to update/display data. In past I did everything in main thread, but every time user selected an item, it was taking 1-2 + seconds to populate the widget with data... Killing interactivity. Tricky...

Its frustrating that widget creation happens in main thread the same that user uses to control widgets... feels like entire widget system should live in another thread and any interaction with it should be done via signals/slots. Then user could select/deselect items and see updates after worker thread process them ? Not sure... maybe I'm thinking wrong :- (

[jsulm]

@Dariusz I don't understand why initialisation of a widget can take so long if data is already available.
Usually it works like this: worker thread does all needed processing and emit a signal with all needed data when finished. The UI thread gets that data in the slot and updates the UI. So, does all your processing happen in the second thread and the UI thread only updates the UI? If so, how can it be so slow? How do you update the UI?

[Dariusz]

@jsulm Neither do I, its fairly complex system. I'm slowly going over it to see how I can rewrite it. However, in meantime is this action somehow possible? >

stuff::doStuff(){ // called from thread.
     processData();
     if(!widgetInitialized()){
          mainThread::takeControl::createWidgets();
     } //// wait for it to finish.
     populateWidgetsWithData();
}
```'
?

[SGaist]

Hi,

As already said, no. Don't manipulate widgets from a secondary thread.

You can get inspiration from QFileSystemModel. The data handling is threaded and the model notifies the view when new things have arrived.

[Dariusz]

@SGaist I'm trying to go back to main thread to create widget and then return to my worker thread to finish processing data... Not do updates on widgets from my thread. I take there is no way to do this then ? I know we can do QFuture if we want to wait on some worker threads to do their work, but can worker thread send work to main thread and wait for that to finish ?

[JonB]

@Dariusz
It's the "waiting" in the middle of code thread for the UI thread that is the issue. Can you at least split your processing thread so that the part after creating a widget is separated off from the part before. Then you can use signals & slots to communicate between the threads.

[SGaist]

Then use signals and slots with Qt::BlockingQueuedConnection as the connection type.

[Dariusz]

@JonB Hey

Ok so I decided to go over the code and rebuild the system....

I have now 4 operation.

1. Initialize widgets on app startup - fine - runs in main loop at app start.
2. Pre-populate widgets with data = Each widget I have is a subclass of Qt widget, it contains a "cached" member which holds "new" value so that finding data/preparring data is stored there. - runs in a worker thread
3. Populate all widgets with data = essentially use cached value and set as widgetData. = run in the Main thread. / these widgets may be hidden/visible at this time
4. Display proper widgets, as they will depend upon selection. - here is where they become visible = done in Main Thread.

With this "new" system... As far as I can tell, point 1 and 2 are fine. Point 3-4 can be slow. I can have a number of data sets, say 20 QWidgets ech containing 50-100 QlineEdits + so there might be 500+ widgets that needs updating at a time.

When I click now, its fairly fast. A tiny lag but nothing as big as last time. I have some ideas how I could optimize it further, mainly fire updates depending on selection, whenever its single click or multi selection(ctrl/shift).

Other than that no idea how to optimize it further. At this points it seems to be just Qt related as all the point 3/4 is doing is updating widgets width data & displaying them.

---

@SGaist said in Creating widgets in "another" thread...:

Then use signals and slots with Qt::BlockingQueuedConnection as the connection type.

Woa this takes control over main thread & return afterwards?! Sweeeeeet! Will try it, I have some ideas now :D

[J.Hilk]

@Dariusz have you tried this in release mode as well ? 500 widgets is a number that should be easily handled.

[Dariusz]

@J-Hilk I'm developing now in Release with Debug info in Release "mode"... its a bit confusing, but as far as I can tell its the "fast" mode. In debug only mode it is a lot slower. But thats due to filtering arrays/etc/etc so I think its "normal"

[J.Hilk]

@Dariusz
you mean you call the compiler with -g -O3 ?

[Dariusz]

@J-Hilk I'm not actually sure... I use cLion and one of their presets... when I did cmake print flags these were the flags:

CMAKE_CXX_FLAGS_RELWITHDEBINFO is /MD /Zi /O2 /Ob1 /DNDEBUG

[J.Hilk]

@Dariusz I'm not really fluent with make 🙈 But I think its equal to -g -O2

Never the less, there's still room for optimization and, removing the /DNDEBUG should increase the performance too.

You're currently in a fast debug build, and at the very least this should not be the production build :)

[SGaist]

@Dariusz said in Creating widgets in "another" thread...:

say 20 QWidgets ech containing 50-100 QlineEdits

When I see that many QLineEdit, I usually wonder if QTableView/Widget would not be a better fit to show the data.

[JonB]

@Dariusz
Sorry to make a post to just confirm what @SGaist has said above, but 20 * 75 == 1,500-odd line edits average. That's a lot! (And I pity the user who has to fill those in ;-) ) I think the suggestion that you look at the possibility of some kind of table instead needs reiterating. And @VRonin will then be here to ensure that you achieve this using item delegates instead of widgets in your table, so it will all be fast and not use up too much memory/resources ;-)

[nintyfan]

I have similar problem
I am creating small wrapper around Qt. I need to process poll in another thread. QSocketNotifier is not solution - it lacks of HUP event support. So, I need to allow call new QPushButton (for example) inside another thread. Signal is not solution, because QApplication::exec could not been called yet. So, if I do not process widget creation in another loop, I will have dead lock.

[Christian Ehrlicher]

@nintyfan said in Creating widgets in "another" thread...:

Signal is not solution, because QApplication::exec could not been called yet

So how do you show the push button then? Your design looks flawed.