On Tue, 28 Jun 2005 19:52:37 +0200 Benedikt Meurer <[EMAIL PROTECTED]> said:
> Been thinking about how to do the thumbnailing stuff lately. With the > current icon loading/caching and the file/folder code, we have a file > manager that loads large directories faster than any other file manager > I've installed on my system, where "load" means that the folder is > completely loaded and displayed. The MIME stuff currently adds the most > slow-down (and some oddities in the treeview layouting code). But from a > rather inaccurate benchmark (from warm cache), Thunar loads > /usr/local/bin (1150 items) faster than ROX, Nautilus, Konqueror or > Xffm. The folder contains mostly binaries (surprise, surprise), where > the MIME code has to read the files to determine their type, which is > pretty slow with the currently imported xdgmime code in libexo. Now that > test wasn't fair because ROX and Thunar are actually cheating. ;-) > > ROX is cheating, because it doesn't determine the type based on the > contents if compiled w/o gnome-vfs. Instead they use only the file name > to guess the type, which is of course way faster. I recompiled ROX with > gnome-vfs now, but didn't check again. It's pretty clear that it'll be > slower now, tho. > > Thunar is cheating, because it doesn't contain any logic for the > thumbnailing stuff currently, which saves some time per file. Also, > there is some other stuff, that isn't handled by Thunar yet, but nothing > that would really add much noticable time to the folder loading stage. > > The only "file manager" that was actually faster than Thunar is GNOME > Commander, but I don't count it as a real file manager, since it doesn't > determine the MIME type for files and also doesn't load appropriate > icons for the files (and has some other oddities). No wonder it's > faster, as it's cheating^2. :-) > > So, to continue with the thumbnailing stuff, we have basicly two > alternatives: > > 1) Use thumbnails, like other file managers do, in place of mime icons > in the icon/details view, scaling them to the appropriate size as > required. The implementation would look similar to the one found in the > filer snapshot, tho not using D-BUS for the generator this time. > > 2) Add a separate 'Thumbnail view'. I discovered this in Windows > Explorer recently. > > My two cents: 2) is better from the implementation's POV, while 1) is > more consistent with what's available currently. That said, if > thumbnailing will not be taken into account with the usual icon/details > view, the time spent per file will be reduced (esp. read()'ing stuff in > ~/.thumbnails/ on NFS home dirs), and with a dedicated thumbnail view, > we could add some nifty stuff like zooming and maybe even previewing > videos and such w/o blowing (and thereby slowing down) the usual views. I'm really not sure either way - I'd probably prefer - as a user - 1 (I don't want to switch view modes to get a preview of the image I'm looking for, esp. since Thunar doesn't have a toolbar button to switch views in it's current iteration), but I can't say it's all that important. One important thing though, is that the list gets displayed quickly, and doesn't freeze the filemanager while listing (Nautilus (2.10) *does* freeze when listing large dirs). This probably means that one thread lists files and determines mimetype, and draws it with the generic icon, then dumps it into a queue for the thumbnailer thread (or even process - more secure, more robust?) to generate and display the thumbnails. -- The one good thing about repeating your mistakes is that you know when to cringe. _______________________________________________ Thunar-dev mailing list [email protected] http://foo-projects.org/mailman/listinfo/thunar-dev
