Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
Performance problems with bulk showing/hiding widgets.
Narnith last edited by
An application I'm developing has, among other things, a scroll view containing many instances of a custom widget, which are created at run time. This widget (technically a QFrame) contains two QPushButtons and three QLabels, one of which is always showing an image - think 200x150 pixels, ish. Each widget has a unique picture, again generated at runtime. There are potentially a very large number of these widgets, think along the order of 2-3 thousand.
Now, the problem I'm running into is this: the application contains a search functionality that is used to show/hide some of these widgets based on the input criteria. When the program decides whether to hide or show a widget, it calls either show() or hide() on it. I've noticed that show() is much slower than hide(), which makes sense. However, due to the number of widgets, it results in lag times that are unacceptable.
I'm not sure how I can go about solving this problem. I've thought about trying a QStackedWidget, with one page for the currently shown widgets, and other for the "hidden widgets" (not really hidden, just on in a view on another page or something), and moving them between the pages as appropriate, but I have no idea if that would be faster at all. At this point in my search I'm very willing to do dirty hacks.
Hi and welcome to devnet,
I'd rather try to bring the number of widgets down. Do you really need that many at the same time ? Wouldn't having only a fixed number of them and then updating their content be something doable ?
Narnith last edited by
[quote author="SGaist" date="1424381935"]Hi and welcome to devnet,
I'd rather try to bring the number of widgets down. Do you really need that many at the same time ? Wouldn't having only a fixed number of them and then updating their content be something doable ?[/quote]
Thanks for the reply.
I've thought about doing that, and if I don't find a solution I may end up going with this. But it's not how the application is expected to work.
RAM isn't a concern in the slightest, so that's not a problem either.
alex_malyu last edited by
Ram may be not a concern, but performance is.
Allocation/deleting memory, construction/deconstruction is a performance killer.
Most approaches implemented in Qt ( QTableWidget for example) follow the design pattern SGaist mentioned.
I bet for a reason.
alex_malyu is right RAM is not everything.
If you really need that much controls you might better go with QGraphicsView and friends but don't put widgets in there