Creating widgets in "another" thread...

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