Multithreading, - widget generation...
-
wrote on 11 Nov 2018, 01:37 last edited by
Hey
Soo I have one of those cool issues... I have a scenario where user can select an x amount of items and at the same time each item could be a parent to 1-5+ items, meaning that a selection of 5 items could result in 45 items selected, each item needs a widget to represent its data, and the widget content can vary, from 5-10 input widgets to 50. As you can see simple selection just turned in to 2250 input widget generation... Now I was running some tests/back and forth and yeah its a bit of a pickle. Each input widget is extended with a "handler" class that connects its output to a proper map so that all data gets updated properly.
So it does take a little time to generate 1 widget. I was thinking of starting a thread and send a queue of new selections to it every time User would select a new item, but then I remembered... QWidgets can only be created in main thread, which brings me to a point of... well "crap". What do I do now? Can any1 suggest any solution? I'm at loss here :- (
TIA.
-
Qt Champions 2022wrote on 11 Nov 2018, 04:06 last edited by dheerendra 11 Nov 2018, 04:07
Are you dynamically creating all the objects(2250) when the selection happens ? Did you check which operation takes time ? It could be that your object creation itself is taking lot of time.
-
Lifetime Qt Championwrote on 11 Nov 2018, 08:37 last edited by Christian Ehrlicher 11 Nov 2018, 08:38
I wonder how someone could find something useful when he sees 2.5k widgets on a screen. What do you really want to achieve here?
2.5k widgets on a 1920x1080 - every widget will have only 20x40 px... -
wrote on 11 Nov 2018, 08:38 last edited by Dariusz 11 Nov 2018, 09:53
As far as I can tell, there is a lot of this that happens in vs cpu usage, but all of it is just qt stuff
https://pasteboard.co/HME3X4X.png
So not sure. I'll dig around see if its my objects, but they are rather light. Usually, just a map + connect wrapper.@Christian-Ehrlicher Well its not 1920x1080 as screens go up to 4k on average in our work environment and its not uncommon that some users have 2-3 of them. But nevertheless the widgets are stored over top of each other and user only shows 1 widget at a time. However an instance widgets can be generated for each attribute view, meaning that 1 node can be shown in 10 places, requiring 10 input widgets to be instanced - now all of that happens internally but its just the share amount of generation that seems to be the problem - and I havent yet decided to generate widgets on demand as the system is a little complex. Its a lot easier to get a list of attribute views, get their filtered content that they accept and generate a widget per content. & instance it I wish I could just send the task to happen in a separate thread, and once he's done just get a call back with a vector filled with widgets. Then I could allow the user a more "fluent" workflow.
-
As far as I can tell, there is a lot of this that happens in vs cpu usage, but all of it is just qt stuff
https://pasteboard.co/HME3X4X.png
So not sure. I'll dig around see if its my objects, but they are rather light. Usually, just a map + connect wrapper.@Christian-Ehrlicher Well its not 1920x1080 as screens go up to 4k on average in our work environment and its not uncommon that some users have 2-3 of them. But nevertheless the widgets are stored over top of each other and user only shows 1 widget at a time. However an instance widgets can be generated for each attribute view, meaning that 1 node can be shown in 10 places, requiring 10 input widgets to be instanced - now all of that happens internally but its just the share amount of generation that seems to be the problem - and I havent yet decided to generate widgets on demand as the system is a little complex. Its a lot easier to get a list of attribute views, get their filtered content that they accept and generate a widget per content. & instance it I wish I could just send the task to happen in a separate thread, and once he's done just get a call back with a vector filled with widgets. Then I could allow the user a more "fluent" workflow.
Well, whatever the reason, you can't create or touch widgets in a thread different than the main one (i.e. the GUI thread). You should rethink your design. Either precreate them (which doesn't sound very reasonable), or create on demand.
-
@Dariusz said in Multithreading, - widget generation...:
But nevertheless the widgets are stored over top of each other and user only shows 1 widget at a time.
So why not reuse this widget instead creating a lot of stuff which is not needed at all ... you should really rethink the design instead trying to do just create thousands of useless widgets and then wonder why it does not work. If I would create all my widgets on startup it would take ages too...
-
wrote on 11 Nov 2018, 13:30 last edited by
@kshegunov "Either precreate them (which doesn't sound very reasonable), or create on demand." That's what I'm doing now, I'm precalculating them and then displaying. it just I wish that action would happen in other thread, Maybe I can somehow start another QApplication, do it there, then kill application but keep the widgets?
@Christian-Ehrlicher because depending on type each widget might be instanced to multiple views, meaning that if any of the view user types text it updates all remaining instanced widgets. Its for synchronization. Thats why the current system requires 1 widget per view to be generated. Which mean that there is a lot of generation going on... I wonder, why qt widgets cant be generated in other thread? I take they get added to like "top up most application vector" that stores everything or something, can't that be mutexes or stuff? Weird.
-
@kshegunov "Either precreate them (which doesn't sound very reasonable), or create on demand." That's what I'm doing now, I'm precalculating them and then displaying. it just I wish that action would happen in other thread, Maybe I can somehow start another QApplication, do it there, then kill application but keep the widgets?
@Christian-Ehrlicher because depending on type each widget might be instanced to multiple views, meaning that if any of the view user types text it updates all remaining instanced widgets. Its for synchronization. Thats why the current system requires 1 widget per view to be generated. Which mean that there is a lot of generation going on... I wonder, why qt widgets cant be generated in other thread? I take they get added to like "top up most application vector" that stores everything or something, can't that be mutexes or stuff? Weird.
@Dariusz said in Multithreading, - widget generation...:
it just I wish that action would happen in other thread
Nope. It's simply impossible.
-
wrote on 11 Nov 2018, 16:25 last edited by
Do you mean that the UI should be responsive and the user could do something useful while the widgets are generated and shown one by one? You can probably use a zero timer signal and a slot for that. In this way everything happens in the same thread but the signals created by user interactions are handled between timer signals.
4/9