Re: [evolution-patches] Re: [Evolution-hackers] Patch for image scale down
- From: Jeffrey Stedfast <fejj ximian com>
- To: Frederic Crozat <fcrozat mandrakesoft com>
- Cc: evolution-hackers lists ximian com, evolution-patches lists ximian com
- Subject: Re: [evolution-patches] Re: [Evolution-hackers] Patch for image scale down
- Date: Wed, 08 Oct 2003 11:49:18 -0400
looks fine.
On Wed, 2003-10-08 at 06:12, Frederic Crozat wrote:
> First, sorry for the wrong mailing list :((
>
> Cc: evo-patches..
>
> Le mer 08/10/2003 à 01:56, Not Zed a écrit :
> > On Wed, 2003-10-08 at 01:24, Frederic Crozat wrote:
> > > The attached patch make evolution uses
> > > gnome_thumbnail_scale_down_pixbuf instead of gdk_pixbuf_scale_simplified
> > > if it is available (ie on GNOME platform >= 2.2), which fixes big
> > > performance problem when it tries to scale down big images (see bug
> > > http://qa.mandrakesoft.com/show_bug.cgi?id=6065 ). It also seems mini
> > > pixbuf is re-computed when switching from open to close for inline
> > > attachement (I didn't fix this problem).
> > Hmm, they should be cached, in 1.4 anyway, head doesn't from memory.
>
> Well, my patch is for 1.4 and I can see it isn't cached at all when
> pressing the arrow attachement button..
>
> I did some checks and pbl->cid changes each time message is reloaded and
> when you press arrow attachement button, therefore cache purpose is
> defeated :(
>
> > > This is a known problem in gdk_pixbuf_scale (which can be workarounded
> > > by using gdk_pixbuf_loader_set_size, only with GTK+ 2.2).
> > If you need gtk+ 2.2 for it, shouldn't it just use that directly? And
> > what happens if you use that on pre 2.2 versions, i.e. does it have a
> > detrimental affect, or is it just effectively ignored.
>
> Ok, I wasn't clear enough :
>
> to fix the scaling performance on very big images to do thumbnails, you
> can either :
> -use gnome-thumbnail_scale_down_pixbuf which is in libgnomeui >= 2.2 (I
> could also copy/paste the function code which is only using gdk-pixbuf
> 2.0 code), which can be up to 100x faster than gdk_pixbuf_scale_simple
> in these cases. So we only need gtk+ 2.0 in this case.
> -use gdk_pixbuf_loader_set_size call, which was introduced in gtk+ 2.2
> and will require more changes in the code, since loader is used for
> loading both full size and thumbnail image.
>
> > > Can I commit this to CVS (both branches, I guess) ?
> >
> > This codepath is completely different in head, tho i guess the same
> > issue will arise.
>
> Well, I must confess I didn't look at HEAD yet :)
>
> > FWIW i tested the test message on the bug, and i didn't see what i
> > would've considered any more delay than i'd expect for such a large
> > image - 1/2 to 1 second was all to build the thumbnail.
>
> Well, you must have a very fast system or with a lot of memory (I'm not
> sure which factor is the most important) :
> on my test system (PIII/450) , it takes :
> -1min25s to render thumbnail with gdk_pixbuf_scale_simple
> -2s with gnome_thumbnail_scale_pixbuf
>
> I think we have a winner here :)
>
> > As for the patch, what defines GNOME_THUMBNAIL_H? Isn't it ...
> > gnome-thumbnail.h?
>
> Hmm, I should have tested my patch better :))
>
> I've fixed this in the new attached patch..
--
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
fejj ximian com - www.ximian.com
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]