Hi. Thanks for the reply.
later.
The proper answer to this is that you need to run this through a
profiler. You know, premature optimization...
If your code runs on Linux, you should take a look at KCacheGrinder.
Indeed, and this has been mentioned by someone else on the team... right
now, it's just an issue of time. Lots of important stuff on the table.
Impossible to answer, when you don't know what the problem is.
I *really* don't like the *Widget versions, and will always tell my
customers to go with a proper model (not a QStandardItemModel based),
but that's for other reasons.
I will be looking into Model/View for future projects, but *most* stuff
until now is a rather small set of data, that changes somewhat rapidly,
and from different sources. Definitely beyond the scope of this email.
My main resistance to this is that while the data is somewhat simple, I
already have a pretty complex system to filter what should be displayed
and what shouldn't, what colors should be displayed for visible items,
what font to use, and whether a sound should be played or not. This is
all configured by the user in the GUI.
Aha, that might very well be the reason. You should try and remove the
filter code completely and see if this solves the problem. Those filters
can be very expensive to calculate.
The checks themselves are pretty light (usually boolean or an integral
comparison). The actions are another story, but even then, it's almost
always a cell coloration. But, for this particular instance I was
checking, he has just a plain vanilla view. No checks, no colors, no
sounds, no nothing... just lag. :/
The main difference is hardware, and the Window Manager. My guess is
it's hardware. I think we'll upgrade first and then revisit the problem. :)
-Paul
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
