On Tue, 2008-09-16 at 14:42 +0200, Philip Van Hoof wrote:
On Tue, 2008-09-16 at 13:30 +0100, Rob Taylor wrote:
I guess when Philip's thumbnailer daemon is starting to get widely used,
It could do the job of cleaning the cache. This would mean that you
would no longer have thumbnails lying
On Mon, 2008-09-22 at 18:19 -0500, Federico Mena Quintero wrote:
On Tue, 2008-09-16 at 11:34 +0200, Stephane Delcroix wrote:
Since 2.23.1, gnome-settings-daemon contains a housekeeping plugin that
clean the .thumbnails. Even if it looks fair, it really makes the F-spot
usage awful to the
We could totally use some liboil/profiling ninjas to work on libjpeg to
make it faster. Then, maybe thumbnailing on-the-fly wouldn't be
painful.
Ooh, yes, please! And the gdk scaling routines are very slow and
memory-intensive for large-ratio downscaling, which is unhelpful too.
or
On Mon, Sep 22, 2008 at 10:41:44PM -0400, Matthias Clasen wrote:
2008/9/22 Ted Gould [EMAIL PROTECTED]:
On Mon, 2008-09-22 at 18:19 -0500, Federico Mena Quintero wrote:
JPEG loading with libjpeg is currently really slow (the benchmark being
Photoshop, which is really goddamn fast for
On Mon, 2008-09-22 at 22:41 -0400, Matthias Clasen wrote:
2008/9/22 Ted Gould [EMAIL PROTECTED]:
On Mon, 2008-09-22 at 18:19 -0500, Federico Mena Quintero wrote:
JPEG loading with libjpeg is currently really slow (the benchmark being
Photoshop, which is really goddamn fast for JPEGs).
On Tue, 2008-09-23 at 21:04 +0200, John Stowers wrote:
snip
There is also epeg, from Enlightenment, and I quote them, an IMMENSELY
FAST JPEG thumbnailer library API.
Which seems to be very deprecated:
http://trac.enlightenment.org/e/changeset/35550
And used libjpeg anyway:
On Tue, 2008-09-23 at 13:31 -0700, Bastien Nocera wrote:
On Tue, 2008-09-23 at 21:04 +0200, John Stowers wrote:
snip
There is also epeg, from Enlightenment, and I quote them, an
IMMENSELY
FAST JPEG thumbnailer library API.
Which seems to be very deprecated:
On Tue, 2008-09-16 at 11:34 +0200, Stephane Delcroix wrote:
Since 2.23.1, gnome-settings-daemon contains a housekeeping plugin that
clean the .thumbnails. Even if it looks fair, it really makes the F-spot
usage awful to the point it's basically unusable.
A semi-related point:
JPEG loading
On Mon, 2008-09-22 at 18:19 -0500, Federico Mena Quintero wrote:
JPEG loading with libjpeg is currently really slow (the benchmark being
Photoshop, which is really goddamn fast for JPEGs).
We could totally use some liboil/profiling ninjas to work on libjpeg to
make it faster. Then, maybe
2008/9/22 Ted Gould [EMAIL PROTECTED]:
On Mon, 2008-09-22 at 18:19 -0500, Federico Mena Quintero wrote:
JPEG loading with libjpeg is currently really slow (the benchmark being
Photoshop, which is really goddamn fast for JPEGs).
We could totally use some liboil/profiling ninjas to work on
Afaik, other applications with similar problems do keep an ad-hoc cache
in ~/.cache/.
For example, banshee does keep a ~/.cache/album-art/ directory.
Since f-spot has peculiar needs, maybe it'll make sense to move its
thumbnail cache somewhere around there.
Cheers,
Matteo
On mar, 2008-09-16 at
On Tue, 2008-09-16 at 13:34 +0200, Matteo Settenvini wrote:
Since f-spot has peculiar needs, maybe it'll make sense to move its
thumbnail cache somewhere around there.
There's nothing that peculiar with f-spot there. It's just the defaults
in g-s-d that are not very sane and the house keeping
Hi,
On mar, 2008-09-16 at 11:34 +0200, Stephane Delcroix wrote:
Hey guys,
The plugin does something like this:
- clean the thumbnails older than MAX_AGE (default to 60 days)
- clean the oldest thumbnails until the cache size is under MAX_SIZE
(default to 64MB)
I don't get why it work like
Emmanuel Pacaud wrote:
Hi,
On mar, 2008-09-16 at 11:34 +0200, Stephane Delcroix wrote:
Hey guys,
The plugin does something like this:
- clean the thumbnails older than MAX_AGE (default to 60 days)
- clean the oldest thumbnails until the cache size is under MAX_SIZE
(default to 64MB)
I
On Tue, Sep 16, 2008 at 2:30 PM, Rob Taylor [EMAIL PROTECTED] wrote:
could also clean out thumbnails that haven't been *accessed* after a
certain time period, which should give better performance.
How do you do that when 99% of desktop PCs use noatime precisely for
that - perfomance? ;)
--
Patryk Zawadzki wrote:
On Tue, Sep 16, 2008 at 2:30 PM, Rob Taylor [EMAIL PROTECTED] wrote:
could also clean out thumbnails that haven't been *accessed* after a
certain time period, which should give better performance.
How do you do that when 99% of desktop PCs use noatime precisely for
On Tue, Sep 16, 2008 at 01:34:17PM +0200, Matteo Settenvini wrote:
Afaik, other applications with similar problems do keep an ad-hoc cache
in ~/.cache/.
For example, banshee does keep a ~/.cache/album-art/ directory.
Since f-spot has peculiar needs, maybe it'll make sense to move its
Stephane Delcroix wrote:
As long as this plugin stays as is, we only have one choice available:
shout fuck you standards and move our thumbs out of .thumbnails. But
I think we can figure out an arrangement:
1) the MAX_SIZE should be set to 0 by default, so the cleaning is only
done one the
On Tue, Sep 16, 2008 at 01:30:30PM +0100, Rob Taylor wrote:
Emmanuel Pacaud wrote:
Hi,
On mar, 2008-09-16 at 11:34 +0200, Stephane Delcroix wrote:
Hey guys,
The plugin does something like this:
- clean the thumbnails older than MAX_AGE (default to 60 days)
- clean the oldest
Philip Van Hoof wrote:
On Tue, 2008-09-16 at 13:36 +0100, Rob Taylor wrote:
Patryk Zawadzki wrote:
On Tue, Sep 16, 2008 at 2:30 PM, Rob Taylor [EMAIL PROTECTED] wrote:
could also clean out thumbnails that haven't been *accessed* after a
certain time period, which should give better
On Tue, Sep 16, 2008 at 8:59 AM, Dr. Michael J. Chudobiak
[EMAIL PROTECTED] wrote:
Right now .thumbnails grows without limit, which isn't good. The average
user is surprised to find a 100 MB thumbnail cache in a hidden directory.
Mine is 800M, which is 10% of my entire /home partition. And this
(resend, as I was not subscribed on this mailing list)
On Tue, 2008-09-16 at 13:30 +0100, Rob Taylor wrote:
Emmanuel Pacaud wrote:
Hi,
On mar, 2008-09-16 at 11:34 +0200, Stephane Delcroix wrote:
Hey guys,
The plugin does something like this:
- clean the thumbnails older than MAX_AGE
On Tue, 2008-09-16 at 13:30 +0100, Rob Taylor wrote:
Emmanuel Pacaud wrote:
Hi,
On mar, 2008-09-16 at 11:34 +0200, Stephane Delcroix wrote:
Hey guys,
The plugin does something like this:
- clean the thumbnails older than MAX_AGE (default to 60 days)
- clean the oldest thumbnails
On Tue, 2008-09-16 at 13:36 +0100, Rob Taylor wrote:
Patryk Zawadzki wrote:
On Tue, Sep 16, 2008 at 2:30 PM, Rob Taylor [EMAIL PROTECTED] wrote:
could also clean out thumbnails that haven't been *accessed* after a
certain time period, which should give better performance.
How do you do
I don't think f-spot needs to abandon the whole thumbnail spec. That's a
bit dramatic.
We'd prefer not. Whatever the way we handle the thumbs, inside or
outside of the specification, it's gonna take a lot of space
It's no big deal to modify the default MAX_AGE and MAX_SIZE settings to
For the people new to the discussion about the thumbnailer DBus spec,
here's[2] a working prototype that will compile on a typical desktop.
If you have Gdk and GStreamer, it'll already make thumbnails for all
supported formats in GdkPixbuf and for mpeg videos. More formats, if
supported by
On di, 2008-09-16 at 09:44 -0400, Dr. Michael J. Chudobiak wrote:
Stephane Delcroix wrote:
Whatever the MAX_AGE, at the time you're passing the threshold, you're
screwed.
About providing a UI, we're not in favor of that. A decent solution
could be to prompt the user with a UI like the
Stephane Delcroix wrote:
Whatever the MAX_AGE, at the time you're passing the threshold, you're
screwed.
About providing a UI, we're not in favor of that. A decent solution
could be to prompt the user with a UI like the f-spot thumbs cache is
taking 90% of the thumbnail allowed space. Grow that
28 matches
Mail list logo
