QTreeWidget speed, was Re: KListBox/KIconView/KListView

[Simon Hausmann]

On Wednesday 04 January 2006 22:38, Matt Newell wrote:
> On Wednesday 04 January 2006 15:13, Benjamin Meyer wrote:
> > [snip]
> >
> > > and on that topic, hopefully QTreeWidget will be made to be non-slow in
> > > 4.2 too. try adding 100,000 items to a QTreeWidget and watch how adding
> > > slows to a crawl =/
> >
> > For those who haven't seen it, one problem I saw was that as you added
> > one row at a time (vs one big block insertRows(0,10000) ) it was taking
> > longer and longer, adding 100 rows to 100 was taking 200ms, 100 to 10,000
> > was taking 8000ms. etc"  Adding 10,000 rows could take a number of
> > seconds. Not good
> >
> > But do not fear!  I have profiled and improved (dramatically in some
> > places) a number of spots in itemviews, in particular when data changes
> > and when new items are added to tree view and tree widget.
> >
> > Adding 100 rows now takes about 5ms be it to 100 or 100,000 :)  The fixes
> > will be in 4.1.1.
> >
> > Course when you have 100,000 items you probably want to have your own
> > model. Models are cool*.
> >
> > -Benjamin Meyer
> >
> > *delegates are there own class of cool because they facilitate eye-candy.
>
> This sounds good, but another speed problem on linux is text painting, it
> can cause large treeview widget with many columns to take a lot of time to
> paint. This patch speeds up text painting quite a bit for me, not sure if
> it is correct.  It causes XRenderCompositeText32 to be called per line
> instead of per glyph.  This should really be looked into, because it really
> causes most of the drawing slowness for my apps.

Unfortunately this patch breaks kerning.

Simon