[Interest] need advise on QStandardItemModel vs. QAbstractTableModel

[Frank Rueter | OHUfx]

Thanks Andreas, that all makes sense.
Will give the more manual approach some more attention.

Cheers,
frank

On 14/01/16 12:00 pm, Andreas Pakulat wrote:
> Hi,
>
> On Wed, Jan 13, 2016 at 11:07 PM, Frank Rueter | OHUfx 
> <frank at ohufx.com <mailto:frank at ohufx.com>> wrote:
>
>     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?
>     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.
>
>     Any thoughts on the above?
>
>
> First of all: Take this with a grain of salt, I haven't written a 
> custom item model since a few years now and have also not kept up to 
> speed with changes in the QStandardItemModel.
>
> One thing to keep in mind with the item model is that it requires to 
> create an object for each and every item. That onehas a another object 
> as d-pointer which then has a bunch of member variables that also need 
> memory. So depending on what you use from it and how many items you 
> have, your memory footprint increases quite a bit without providing 
> anything that you actually use.
>
> The idea with the custom model is that you only have the data in 
> memory that is really 'stored' and you calculate everything for the 
> view on the fly (like colors etc.) from this bare minimum of data. So 
> the memory footprint can get smaller with this - especially with a 
> huge number of items - but of course it means access to the data must 
> be fast. Or you need to consider to cache some (but not all) of the 
> data 'up front' to make it seem fast (I think this happens - behind 
> the scenes - with sql table models based on queries).
>
> You could still benefit from imlementing a custom model event if it 
> replicates some of the item model's logics. If the struct you use for 
> storing the attributes to be returned from data() is considerably 
> smaller than the qstandarditem class your overall memory footprint 
> might decrease while the performance is kept at par with the standard 
> item model.
>
> Andreas

-- 
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/d54d0e77/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/d54d0e77/attachment.png>