[Solved] Every inserts triggers repaint in QListWidget (or any other container)?
-
Hi. I'm not sure how Qt widgets work, because it uses alien widgets. In .NET or even Delphi, we are able to disable windows message processing temporary to add several items in List widget or any other containers and then enable it, so all items will be painted once after every item is inserted in the list. This gives us a speed boost. I'm not sure if this is possible in Qt at all, or even, if it's nessecary.
So what is the fastest way to insert multiple items in QListWidget?Thanks
-
It might be more efficient to use a QListView instead. You can then easily use either your own model that you can update in one go, or even build up a model like a QStandardItemModel and only after filling it setting it as the model for the view.
-
Thank for your reply Andre. Actually, I don't think switching to Model View will solve my problem. Imagine the following scenario:
No matter I'm using Model/View or standard QListWidget, after every insertion, the inserted item becomes visible in the widget, this means that if I'm inserting n amount of rows in Qlistwidget/view, the QListWidget/View will be repainted n amount of times.
However, what I want is to tell QtGui framework not to repaint anything until I finish inserting all my items. That way, say if I try to insert 100 items in a widget, the widget will be repainted once instead of 100 time.
I'm not sure, but I think is issue is actual with Model/View, because QListView has to query/interview my model and then draw it in the widget one by one. Correct me if i'm wrong -
You are wrong. It can help, as it gives you far more control on when you signal the views to do their updating. It also gives you the option to only set the model on the view after you have already filled the model with data.
Of course you can block signals from the model to the view (QObject provides the blockSignals() method for that), but you have no access to the model if you use QListWidget. I would avoid this route if possible, as you will have to find some other way to trigger a complete update of the view then.
-
Thank you very much for clearing things up. I will still wait for another solutions if any until I mark the question as Solved. I'd prefer not to switch to Model/View for now at least.
-
Best of luck with that then. The price you pay for the convenience of using the *Widget version of the model view classes, is a lack of flexibility. That's what you are running into now. Personally, I think they were a Bad Idea(TM) to introduce, and their structure is just plain wrong. But, we'll have the live with the fact that they are here.
-
Hello,
I agree with Andre. Typically switching from QListWidget into QListView + QStandardItemModel is rather quick and painless and gives you a lot of extensibility and flexibility, on the other hand QStandardItemModel is very easy to use.
However, if you decided to stay on the QListWidget and manual adding a lot of QListWidgetItems is a performance issue for you, you can just block repainting i.e. via QWidget's updatesEnabled property when adding those items.
@
qlistwidget->updatesEnabled(false);
//add many many items
qlistwidget->setUpdatesEnabled(true);
@
After that it may be necessary to manually call the update() slot on qlistwidget. -
@gmaro thank you very much, that's what I wanted to know :)
I'm planning to switch to Model/View after the product gets to beta stage.Thank you guys :)
-
Might I suggest that if you start to use this method, you at least wrap it in a small RAII class? It is quite simple to exit your procedure without calling setUpdatesEnabled(true) again...
-
Thanks Andre, it's a good idea :)