[Interest] need advise on QStandardItemModel vs. QAbstractTableModel

Frank Rueter | OHUfx frank at ohufx.com
Thu Jan 14 01:10:40 CET 2016


Thanks Bo,

I made some progress with QStandardItemModel, an d will try to pull even 
with the QAbstractTable model approach, hopefully that will help getting 
a feeling for it all.

 >>If you have performance issues with a QAbstractTableModel over a 
QStandardItemModel, you're doing something >>wrong.
In my case I definitely did by putting all the calls to the external 
objects int' the data() method. I will rework this to prepare all that 
up front and make the required data accessible to data().

Cheers,
frank

On 14/01/16 11:46 am, Bo Thorsen wrote:
>
>
> Den 13-01-2016 kl. 23:07 skrev Frank Rueter | OHUfx:
>> Thanks Bo,
>>
>> when you say "it's bad in so many ways", are you referring to 
>> performance?
>>
>> I just realised that my last conversation with Jason had dropped the CC
>> to the list, so here it is again :
>>
>>     so a few lines into the new code and I believe I'm starting to
>>     realise that QAbstractTableModel is the wrong choice for me, let's
>>     see if I get this right:
>>
>>     I need each cell to:
>>
>>       * store a reference to a custom object in the host application
>>       * get it's background and foreground colour from the host
>>         application's object
>>       * determine the right delegate output based on the data type/
>>         external object class
>>       * drive the external object's value upon datatChanged
>>       * etc.
>>
>>     When I got as far as implementing the background role in my
>>     QAbstractTableModel's data method, the resulting view took about 4
>>     seconds to resize, while scrolling left me with the ol' spinning
>>     beach ball (OSX).
>>     The same code utilising QStandarItemModel reacts instantaneously
>>     without trouble, even with way more data.
>>
>>     I suppose this is because I am storing those object references in
>>     each QStandarItem as I construct the data when using
>>     QStandarItemModel. So later on, those values are readily available
>>     within my data model.
>>     When putting those references into QAbstractTableModel.data(), they
>>     are constantly called upon as the view changes, causing the massive
>>     slow down.
>>
>>     In order to keep the view fast, I need to refactor my code and
>>     somehow store the custom data only once, so things like background
>>     colour etc. are determined within my model's data when needed,
>>     rather than having to call the host application constantly to
>>     retrieve the same info.
>>     Which essentially turns the table model into an item model, and I
>>     might as well use the QStandardItemModel or at least
>>     QAbstractItemModel to begin with.
>>
>>     Does that sound about right?
>>
>>
>> Bo, reading your reply makes me feel like I should keep playing with
>> QAbstractTableModel (or QAbstractItemModel) and write all the behaviour
>> I need from QStandardItemModel myself?
>
> Well, you almost already answered the question yourself. It's obvious 
> your access from data() the real model is where the problem lies.
>
>> I feel like the item based approach is handier as I can subclass a
>> QStandardItem and give it a reference to the external object it
>> represents, then have the data read/write from/to that.
>> I don't think I get that with a table model unless I re-invent the 
>> wheel.
>
> MyObject** references;
>
> Can't be much faster than that.
>
>> Any thoughts on the above?
>
> To me QStandardItemModel is a quick hack I sometimes use when I just 
> want to show a bit on the screen. But those temporary things have a 
> tendency to stick around, and at some point I always end up rewriting 
> the stuff with the real thing.
>
> If you have performance issues with a QAbstractTableModel over a 
> QStandardItemModel, you're doing something wrong.
>
> I think the only place where I might use a QStandardItemModel for 
> something real is if you have a static set of information that you 
> just need to show. If it never changes, then it's an easy model to use.
>
> At the DevDays in 2006 (I think) I did a presentation on the model 
> view classes. I basically told everyone that QStandardItemModel is the 
> path to the dark side there as well. And one of the Trolltech guys 
> came up and we had an interesting discussion about it. He did argue 
> that sometimes there are cases where this makes sense.
>
> But I'm biased. I hate that class and I really like the table and list 
> model classes.
>
> Bo.
>
>> On 13/01/16 10:27 pm, Bo Thorsen wrote:
>>> Hi Frank,
>>>
>>> Den 12-01-2016 kl. 22:40 skrev Frank Rueter | OHUfx:
>>>> I just joined this list so hello everybody.
>>>> I'm using QT via PySide mainly to create tools for vfx workflows and
>>>> custom tools for the software Nuke.
>>>> <http://www.thefoundry.co.uk/products/nuke/>
>>>> I'm not a programmer by trade, more of a vfx artist and technician 
>>>> using
>>>> Python/PySide to enhance pipelines and workflows for myself and other
>>>> companies.
>>>> Currently I am writing a custom spreadsheet that will need many custom
>>>> ItemDelegates and a controlled way of data input/output when a cell's
>>>> data is changed.
>>>> I will also need to write a feature that allows for multiple cells 
>>>> to be
>>>> changed at the same time (haven't got that far yet though).
>>>>
>>>> The amount of items will potentially be in the 100,000s and a lot of
>>>> filtering will be going on.
>>>>
>>>> I started using the QStandardItemModel and so far things are working
>>>> fine, but I haven't implemented the delegates or editors yet, and I
>>>> believe I will also have to override the data()/setData() methods in
>>>> order to control how the data is managed on IO.
>>>>
>>>> I can't make up my mind if I should switch to using the
>>>> QAbstractTableModel before proceeding.
>>>> I am using some of the QStandardItemModel's method's, such as clear()
>>>> and item() and setItem(), but I guess those are easy to re-implement.
>>>>
>>>> The docs say that one should consider using QAbstractTableModel (or
>>>> QAbstractItemModel) for efficiency and flexibility, but I am 
>>>> struggling
>>>> to make an educated decision because I haven't used model/views often
>>>> enough yet to know about all the pros and cons, and I can't find a
>>>> discussion concerning this online.
>>>>
>>>> I have started re-writeing the code using QAbstractTableModel, 
>>>> trying to
>>>> get to the same level I'm at with the code using the 
>>>> QStandardItemModel.
>>>> It seems a bit harder than I thought, but I will keep going for 
>>>> training
>>>> purposes if nothing else, hoping that I might even have a more
>>>> responsive model in the end, but I'm just not sure if it's worth it in
>>>> my case, or if I should just stick to the pre-fab QStandardItemModel.
>>>>
>>>> Any advice from more experienced programmers on how to make that
>>>> decision would be very much appreciated. I'd hate to finish writing 
>>>> the
>>>> code only to find out that it's too slow for large data sets, and then
>>>> re-jig everything to use the QAbstractTableModel.
>>>
>>> To me, the standard item model has always been something I use as
>>> little as I can. It's bad in so many ways. But I do understand why
>>> sometimes it's a quick fix for a small problem.
>>>
>>> Implementing a proper table model is not as easy, but in the long run
>>> you will prefer it. Once a proper model is done, it just keeps
>>> working. And it can handle the large load you are talking about.
>>>
>>> If it was me, I wouldn't have to think about this. It's a clear case
>>> of a proper table model.
>>>
>>> Bo Thorsen,
>>> Director, Viking Software.
>>>
>>
>> -- 
>> ohufxLogo 50x50 <http://www.ohufx.com>     *vfx compositing
>> <http://ohufx.com/index.php/vfx-compositing> | *workflow customisation
>> and consulting <http://ohufx.com/index.php/vfx-customising>* *
>>
>
> Bo Thorsen,
> Director, Viking Software.
>

-- 
ohufxLogo 50x50 <http://www.ohufx.com> 	*vfx compositing 
<http://ohufx.com/index.php/vfx-compositing> | *workflow customisation 
and consulting <http://ohufx.com/index.php/vfx-customising>* *

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20160114/8921c496/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ohufxLogo_50x50.png
Type: image/png
Size: 2666 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20160114/8921c496/attachment.png>


More information about the Interest mailing list