Hi Robert! First of all, don't confuse gdk with gtk. Using a Gdk.Pixbuf doesn't mean you need a GUI. It's just a pixel container.
I've modified the import process and it's now *much* faster in displaying the import dialog. The actual importing now only happens when you click import. The import itself is still affected by two factors: file copying and hash calculation. While we can't avoid the first one (for obvious reasons), there's much we can do on the second one (more on that in a different mail). We should replace most of import though, to make it faster, a lot more flexible and just to clean up the historical cruft. Ping me if you're interested in helping out, help is always welcome. Ruben PS: apologies for the lack of formatting, this was sent from a tiny keyboard with a client that doesn't wrap at 70 chars. -----Original Message----- From: Robert Latest Sent: 15/05/2010 21:43:06 To: [email protected] Subject: Re: f-spot good enough for 22k+ photos? On Sat, May 15, 2010 at 9:08 PM, Ruben Vermeersch <[email protected]> wrote: > Import is quite problematic right now (and needs to be replaced). I've > just reworked part of it, to make it somewhat better, but it's a known > fact that it tends to swallow memory on import. Hi Ruben, thanks for the reply. Having done some work on exactly this kind of stuff I know that it can be done much more efficiently. In fact I'd really like to modify my GUI-less import tool so it can quickly scan the entire directory tree and add new pictures. Looking at the source, however, I saw that f-spot's MD5 sum generation depends on the availability of thumbnails in gdk-pixbuf format, which sadly locks the entire database<->file interface into an (in my eyes unneccessary) dependency on the GUI. In order to faciliate interfacing to non-GUI and/or non-GTK tools I would propose to base the MD5 sum generation on the file contents alone. I would also lose the thumbnail display on import, therefore making the whole procedure a lot less ressource hungry. Like I stated above, I can MD5 hash my entire photo dirtree (44GB/20k photos) in just a few minutes and file the hashes as well as lots of EXIF metatdate in a sqlite db in just a few minutes. I'm too geeky and know too much about what's neccessary and what isn't (or at least I think I do) in order to tolerate this. Keep in mind that the first thing an f-spot newbie (like me) wants to do is to import his entire photo collection into the new exciting software. He doesn't want to see the machine grind to a halt while looking at a screenful of well-known thumbnails! But enough rants for now: Thanks for the great work, keep it up! > That being said, we do have users with over 30k photos, so it is > possible. Fixing the problems with memory is a high priority task. Hang > on. Scanning a directory tree and evaluating files one-by-one is extremely easy on memory. I really would like to contribute a non-GUI import tool (in pure C, I know nothing about C#), but that would require the possibility of creating the MD5 sum without GTK dependency. Regards, robert _______________________________________________ f-spot-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/f-spot-list _______________________________________________ f-spot-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/f-spot-list
