KFileItem, mime types, and icons

[Frank Reininghaus]

Hi David,

thanks for the quick and detailed reply!

2013/6/6 David Faure:
> On Thursday 06 June 2013 13:20:06 Frank Reininghaus wrote:
>> 1. My observations
>>
>> The thing is that Peter's code *always* calls
>> KFileItem::determineMimeType() before calling KFileItem::iconName().
>
> Oh.
>
>> Now I wondered if that is really necessary, so I tried the following:
>> called iconName() and iconOverlays() for all items that were received
>> from KDirLister when entering a folder, measured how much time that
>> takes, and then called determineMimeType() for all these items, and
>> measured again.
>>
>> It turns out that icon loading is often *much* faster than determining
>> the mime types, especially in my favourite "see how it works with many
>> real-world items" test cases /usr/bin/, /usr/include/, and /usr/lib64.
>> The icons look OK even though the mime type of many files was
>> apparently not known while the icon was loaded.
>
> This surprises me; any shell script in /usr/bin (without any extension) should
> have an unknown icon if you call iconName() with an unknown mimetype.
> That's ok of course, if the mimetype is determined later on, as discussed
> below. But I dispute "the icons look OK", especially since you said you didn't
> like seeing "unknown" icons :-) Or maybe you get the generic "executable" for
> such shell scripts (e.g. /usr/bin/znew), because they have the +x flag?

Yes. I see that "they look OK" was not very precise. I meant "they are
not unknown".

>> 2. My conclusions
>>
>> I think that we should do the following:
>>
>> (a) When we try to determine icons for the visible items synchronously
>> for 200 ms (we always do that when entering a folder or new items are
>> inserted), we should just call iconName(), maybe iconOverlays(), but
>> definitely not determineMimeType() (unless we sort by type).
>>
>> (b) Later on, when we look at each item in the visible range (and
>> those near the visible range or at the top and bottom of the list)
>> asynchronously, we call determineMimeType() and update the icon.
>>
>> This would greatly reduce the risk that 200 ms are insufficient for
>> loading the visible icons, which results in "unknown" icons being
>> shown to the user, which then only get replaced asynchronously and
>> slowly.
>
> In the code I wrote (i.e. all iterations of file management before dolphin) it
> was almost always like that. First, creating items without mimetype
> determination (fast), then later on mimetype determination, starting with the
> visible items. The 200ms limit is what dolphin introduced in addition, when
> reimplementing all this.
> What you propose sounds good to me (especially since the 200ms limit should be
> hit less often without mimetype determination, so this is quite close to my
> old KMimeTypeResolver algorithm), but at the same time it makes me wonder why
> Peter changed from that to the 200ms algorithm. I seem to remember a
> discussion which said "it's ugly to get wrong icons, very quickly replaced
> with correct icons, it would be better to wait a little bit more (not much,
> just a little bit, hence the 200ms limit) and get correct icons immediately,
> to avoid the effect of seeing one icon replace the other very quick.
>
> So maybe the best fix is rather the following adjustment to the current
> algorithm: after the 200ms timeout, instead of using "unknown" for everything
> other visible items [as you say it does, I'll trust you on that since I don't
> know that code], it should then use iconName() without mimetype determination
> for the other icons.
> I.e. after 200ms, switch from the optimistic "we'll get it all done in time"
> approach to the fallback "ok, we'll do the rest in two stages, so that the GUI
> can keep being responsive". But that fallback should still look ok as much as
> possible, so iconName() rather than "unknown".

This sounds reasonable! And if the visible icons are fully determined
in 200 ms, maybe we should use the remaining time to try and do a fast
icon loading (without determineMimeType()) for all other items, to
reduce the risk that the user ever sees "unknown" icons when
scrolling.

But I think that even the time that we spend on fast icon loading must
be limited, because "fast" icon loading in directories like
/usr/include/ and /usr/lib/ takes several seconds here. Even in
/usr/share/, which consists of 520 subfolders and only 4 files here,
calling iconName() for all file items takes almost 6 seconds(!).

I'm wondering if something goes wrong there - it seems that "fast"
icon loading is particularly slow for folders, even though I would
expect that loading the plain folder icon should be relatively easy.

Am I missing something here?

Thanks and best regards,
Frank