[PATCH/RFC] On the iconview and the speed of directory listing.

[Maks Orlovich]

On Sunday 25 May 2003 01:23 pm, David Faure wrote:
> Very verbose comment - "no iconview" never happens :)

Then why check for it in KIconViewItem::calcRect()? ;-) 
(but yes, I probably shouldn't try to fit a small correctness proof of a 
change in a comment :-) ). 



> > Now, I looked at our calcRect() implementation, and it seems there is no
> > easy way of improving it, as QIconView is not very friendly to overriding
> > calcRect():
> > 1. The old one will get called in the QIconViewItem ctor anyway, as
> > KIconViewItem vtable wouldn't yet be active.
>
> Right. Should we sent qt-bugs a patch that delays
> QIconViewItem::calcRect()? Hmm, sounds a bit difficult, the layouting
> relies on it.
>
> Another idea: we could create items without a parent view (passing 0 to the
> QIconViewItem constructor), then calling insertItem() to insert it, then
> calling calcRect() ?

I am not sure this order will work; QIconViewItem does it the other way around 
(calcRect() and then insertItem() ); when I tried to reverse it in there as a 
performance experiment, it blew up rather badly. (KDesktop would run out of 
memory). 


>
> > 2. The 3 separate set*Rect() calls all do a considerable amount of
> > internal manipulation.
>
> Indeed. This calls for a single setAllRects()...
>
> > Now, I am not sure of what to do WRT to the word wrap case at all.
> > kdelibs's word-wrap is certainly much nicer, but the difference is huge.
> > (If I drop our  calcRect() and paintItem() along with a then-redundant
> > call to calcRect() in KIconViewItem::init(),  slotNewItems takes about 5
> > seconds; total CPU time for Konq at startup in that dir is reported as 10
> > seconds by top). Perhaps if I can figure out why the non-wrapped case is
> > changed so much I'll be able to offer a good option; but I figure it's
> > worth getting this info out...
>
> Ah, so the worse isn't the additional calcRect() call, but the actual
> word-wrap implementation, KWordWrap::formatText()?

Probably not, if you consider the case I patched. There, calling calcRect() 
twice seems to make the huge difference (more like 30x than 2x). I am not 
quite sure why, and I'll try a bit more timings in hope of getting more 
specific information... But I don't understand the class internals, so it 
might be tricky.