Re: [evolution-patches] Re: [Evolution-hackers] Patch for image scale down

[Not Zed <notzed ximian com>]

On Wed, 2003-10-08 at 19:42, Frederic Crozat wrote:
> First, sorry for the wrong mailing list :((
Ahh well, it opened it up for discussion anyway, i've removed the -hackers cc tho.

> 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 :(
Ahh well.  Nobody's really noticed it till now so I guess it can stay.  I'd like to add a cache eventually to head though.

> > > 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.
Hmm, I think in head it's generated separately, but i can't really remember.  An approach at the loader level might be more appropriate, and it already depends on newer libs anyway.  But that depends on if its generated separately.

> > 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 :)
Although i do have a fast box, with plenty of ram (pentium-m 1.5Ghz, 512MB/ram), that difference seems 'quite a lot'.  I wonder if there's some other reason its fast enough on this box.

> > 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..

Ok, It looks ok to me, for 1.4 at least.