From kfm-devel Fri Jun 07 09:37:18 2013 From: Frank Reininghaus Date: Fri, 07 Jun 2013 09:37:18 +0000 To: kfm-devel Subject: Re: KFileItem, mime types, and icons Message-Id: X-MARC-Message: https://marc.info/?l=kfm-devel&m=137059786203592 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