[Qt-interest] QTreeView and custom QAbstractItemModel performance problem

[Andre Somers]

On 9-7-2010 16:41, Felix Brack wrote:
> hy? If you have a table, then what's wrong with using a QTableView?
>    
> By last resort I meant the following: before moving to TableView (which
> is of course not wrong at all) I would have liked to know why the
> decission for the TreeView was wrong, sort of learning to not make the
> same error twice or even more. What I know for sure: If I don't fix it
> (fixing means understanding what is wrong) it will bite me later (could
> be one of Murphy's laws...).
>    

OK, good attitude if you ask me! Better to understand why something goes 
wrong, than to apply a quick fix and just continue and hope it won't 
come back to haunt you...
>>> Furthermore when looking
>>> at what the TableView can do I will have to switch off about everything.
>>> For what I want the TableView is like taking sledgehammer to crack a
>>> nut. I just want a protocol, say 200 lines, first column shows an icon
>>> and when it's full the oldest data gets discarded.
>>>        
>> Well, you can also argue that QTreeView is a sledgehammer then: why do
>> you need a whole infrastructure for keeping track of item trees, open
>> and closed items, etc., if you just display a flat list anyway? And, do
>> you really need multiple columns for what you do? A single column can
>> contain both an icon and a text...
>>      
> In short: I use the infrastructure because it is there. Of course I
> could create a widget and add rows and columns with data myself instead
> of using Qt's Model/View framework. I just thought it would be a good
> idea to use the framework offered by Qt, that assumption might be wrong.
> I need multiple columns to arrange the according to preferences set by
> the user. Again you are right, I could do that by hand too.
>    
No, I did not mean you'd do everything by hand. I did mean to suggest to 
use the right tool for the job though. Qts Model/View framework does 
seem a good fit for the problem, so by all means, use it. The issue is 
to select the right view to have fast layout of your items.
>>> As already stated: I don't think (I might be wrong of course) it is
>>> performance problem of any function in the data model (including
>>> hasChildren). The problem is the view requesting the same information
>>> again and again from the data model. I have been able to prove this with
>>> a very stupid data() function in an earlier post.
>>>        
>> I agree. The item views are not optimal in that sense. For instance,
>> QListView will make *many* calls to the delegates sizeHint(), which in
>> turn makes calls to the models data() and flags() and results in
>> calculating text layouts (expensive operation), and then simply ignores
>> the result! That is something that needs to be fixed in Qt. However,
>> QTableView is much more efficient, as it does not by default ask for
>> size hints because they are not used. You can make a table view look
>> just like a tree view, if that's the issue.
>>      
> That sounds like a very good explanation for what I am experiencing and
> what the profiler reports. It really seems that using a TreeView to do
> this was simply a wrong decision of mine. With this explanetion I think
> I can safely (with respect to learning about Qt's framework) discard my
> code and give the TableView a try. I will let you know about the outcome.
>    
Please do! I hope it fulfills your needs. I am not saying it will be a 
magic bullet though.
Note that you probably don't need to discard much code. QTableView works 
on the same models that QTreeView does.

André

-- 
Nokia Certified Qt Developer.
Interested in Qt related job offers or freelance Qt consulting work.