Creating widgets in "another" thread...



  • Hey

    Before all I know I cant make widget in another thread, or at least make it and parent to widget in different thread... thus... how can I call main thread from my sub thread, create widgets and then return to continue my function?

    say

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

    Any hints?

    TIA


  • Qt Champions 2019

    @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.



  • 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 :- (


  • Qt Champions 2019

    @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?



  • @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();
    }
    ```'
    ?

  • Lifetime Qt Champion

    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.



  • @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 ?



  • @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.


  • Lifetime Qt Champion

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



  • @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


  • Moderators

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



  • @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"


  • Moderators

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



  • @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
    

  • Moderators

    @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 :)


  • Lifetime Qt Champion

    @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.



  • @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 ;-)