sam th --- [EMAIL PROTECTED] --- http://www.abisource.com/~sam/
OpenPGP Key: CABD33FC --- http://samth.dyndns.org/key
DeCSS: http://samth.dyndns.org/decss
>From [EMAIL PROTECTED] Wed Apr 18 13:20:31 2001
Return-Path: <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
Received: from venus.wolf.it (adsl-245-200.38-151.net24.it [151.38.200.245])
by parsons.abisource.com (Postfix) with ESMTP id 1321F13B818
for <[EMAIL PROTECTED]>; Wed, 18 Apr 2001 13:20:30 -0500 (CDT)
Received: by venus.wolf.it (Postfix, from userid 1000)
id 445BF8F9C; Wed, 18 Apr 2001 20:20:27 +0200 (CEST)
Date: Wed, 18 Apr 2001 20:20:27 +0200
From: Paolo Molaro <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: gdk-pixbuf vs. ImageMagick
Message-ID: <[EMAIL PROTECTED]>
Mail-Followup-To: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
In-Reply-To: <[EMAIL PROTECTED]>; from
[EMAIL PROTECTED] on Wed, Apr 18, 2001 at 12:37:28PM -0400
Sender: [EMAIL PROTECTED]
On 04/18/01 Leonard Rosenthol wrote:
> >On unix at least, it would be far better to use gdk-pixbuf:
> >1) it's a lot smaller
> >2) it's faster
> >3) it loads the image libs at runtime only when needed
> >4) it will come anyway for free with Gtk 2.0
> As one of the maintainers of ImageMagick, I'm a bit biased here,
> but do want to have this discussion...
So, people, don't accuse me of starting flamewars this time...:-)
> 1) Yes, gdk-pixbuf is smaller because it only support about 10% (if that)
> of all the functionality of ImageMagick. Now admittedly, a bunch of that
> functionality is overkill for a word processor (eg. when was the last time
> you color corrected or embossed a picture in Word?), but support for vector
> formats like PS, PDF, SVG, WMF will definitely be a nice plume in AbiWord's
> cap that IM can bring "for free".
That 10% is exactly what a WP needs. Moreover vector data should better
not be converted to RGB. We'll want a component to handle that properly
(and probably libsvg for SVG).
> 2) Faster - I doubt it for the same functionality since both products leave
> the "heavy lifting" of image format handling to libraries like libjpg,
I must admit I wrote that because I find myself many times running
display image, hitting ctrl-C and starting Gimp itself, only
to view the image... But this doesn't compare to gdk-pixbuf, so I wrote
a little program to load an image, scale and save it back.
I haven't investigated in what operation libMagick gets slow, but
loading and saving time has a lot to do with the user experience and
scaling needs to be fast because abiword uses it for the display.
Yeah, I now we don't save to png files, but it's just to make
the program comparable to convert...
I tested image sizes 250x250, 600x600, 1329x1515
(with time program args...) and gdk-pixbuf is at least twice as fast.
The program is small enough to inline it here:
#include <gdk-pixbuf/gdk-pixbuf.h>
int main(int argc, char * argv[]) {
GdkPixbuf *pixbuf, *p2;
g_type_init(0);
pixbuf = gdk_pixbuf_new_from_file (argv[1], NULL);
p2 = gdk_pixbuf_scale_simple(pixbuf, 50, 50, 0);
gdk_pixbuf_save (p2, "test.png", "png", NULL, NULL, NULL);
return 0;
}
For ImageMagickk I used convert -scale 50x50 image1.png test.png.
Note also the convert uses 4 times as much memory (as reported with
memprof).
> 3) ImageMagick 5.2 and later also use dynamic loading of the image
> libraries AND our "coder" modules.
Ok, I checked my debian package (version 5.3.x) and the library is linked
to a lot of image libs, should probably file a bug report on the package
so that it's compiled with the dynamic modules.
> 4) That's great - BUT that doesn't help us on all the other platforms (Mac
> OS, Windows, QNX, BeOS, etc.) that Abiword is available on that GTK is
> not. ImageMagick, on the other hand, is available for all of those
> platforms and many others.
Gdk-Pixbuf depends only on GLib (talking about version 2.0 here)
and there shouldn't be any portability problems.
Anyway I don't have any problem with the other platforms using libMagick,
the point is, do not add classes for each image file type, add a single
class that loads many types of images using a library such as gdk-pixbuf,
libMagick or the OS services.
lupus
--
-----------------------------------------------------------------
[EMAIL PROTECTED] debian/rules
[EMAIL PROTECTED] Monkeys do it better
PGP signature
