Speed and Look of IconView browsing.

[Mikolaj Machowski]

Dnia pon 5. kwietnia 2004 02:48, Enrico Ros napisał:
> On Sunday 04 April 2004 21:05, Mikolaj Machowski wrote:
> > Dnia sob 3. kwietnia 2004 20:10, Enrico Ros napisał:
> > > 01 NOT TO BE APPLIED IN SHORT. Eye-candy patch. The user will see the
> > > viewport painted at once, not the growing from the top-left corner;
> > > also suppress flicker due to composting.
> >
> > Great! I applied all of them and spot only one problem. When entering
> > directory with over 6000 files everything freezes for few seconds.
> > Situation is even worse (up to 20seconds) when using open file dialog.
>
> You hilighted 2 points:
> 1) the file dialog suffered the same problem that the konqiconviewwidget
> had. I ensure you that now the file dialog is as fast as the filemanager.
> (it can be more than 4x faster with 6000 items..)

Hmm. I know it is faster but as I was looking at it it was slower than 
filemanager.

> > I understand in this time KDE/Qt are buffering icons before painting
> > them. This is of course extreme situation (local repository of Mdk
> > packages) but maybe something can be done? Progress bar?
>
> 2) In fact only the viewport is buffered, icons are not.. In this
> situation the only different thing should be the cleaning of the
> viewport. The first icons will be displayed at the same time (maybe
> faster) than without the patch applied, isn't it? Maybe we can detect if
> the operation is taking so long and display progress / clear the
> background in that case.

Good idea. 15 secs is too long for NULL reaction, user can be annoyed.  
What do you think is too long? 3secs, 5? I think in most cases it could 
be enough to completely skip 'progress bar' and at the same time show to 
the user if operation is too long that something is done.

m.