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
<fr...@ohufx.com <mailto:fr...@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>* *
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
