[PATCH] Speed up iconView's setIcons 2x...

[Lars Knoll]

A few comments.... 

The repaint in the original patch shopuld probably be an update() call. This 
posts the event (instead of triggering the paint event synchronously), so 
several calls can be merged by Qt. It usually reduces flicker quite a bit and 
should also make it faster.

<cite>
    if ( recalc )
        calcRect();
    if ( redraw ) {
        if ( recalc ) {
            QRect oR = rect();
            calcRect();
            oR = oR.unite( rect() );
</cite>

Looks like you're right here. I'm not the expert on icon views, so I don't 
know if changing the first if statement to if( recalc && !redraw ) could 
break anything, but I don't think so. Just send a mail to 
qt-bugs at trolltech.com about this.

> On Tuesday 13 August 2002 23:51, Maks Orlovich wrote:
> > This is in fact mostly spent KonqKfmIconView::slotNewItems( const
> > KFileItemList& entries ) and suggests that my original patch is probably
> > not the best way of addressing it.. What happens here is that the
> > directory lister cache recognizes the familiar directory, and dumps all
> > of the files in it immediately to the icon view; so the view spends its
> > time processing all the items; and then updating the icons for them
> > before returning to the event loop.. I am thus not sure of what the
> > proper way of fixing this is -- anyone else?
>
> What you could do is remove m_itemDict and use KFileItem::setExtraData() (I
> wanted to do this long ago). With a large directory, the 43 buckets
> dictionary looks a bit helpless.

Otherwise change at least the dict to a QMap<...,...*>. Except that you have 
to delete data yourself, it behaves mostly like a dict without the hash table 
limitations.

> Ouch, and you could change the QPixmap variables in struct
> KFileIVI::Private to pointers, allocating them with new on demand (every
> QPixmap constructor calls XCreatePixmap() IIRC. Those overlays and
> thumbnails shouldn't create that much overhead when they're not used at
> all.

Not true. The default constructor constructs a null pixmap. Null pixmaps 
shouldn't call XCreatePixmap.

Cheers,
Lars