> You did this just to be contrary after the recent discussion
>;). Also, once we get IM in, I'd prefer to see this backed out since it
>would be duplicate code...
It was actually lying around in patch-form on my HD. This discussion sparked
my interest to actually get things working (4 LOC change actually).
Not really contrary to the discussion (I'm the biggest advocate of using IM
actually :) As I see it, we're presented with a few choices:
1) Use libjpeg, libpng, etc... and roll our own classes
2) Use IM on all platforms
3) Use native code/libraries where available/appropriate, use IM otherwise.
Now, IM is (admittedly) overkill for our needs. But it's one helluva sweet
library with lots of supported backends. GdkPixbuf has a lot of good
backends too and has *exactly* the feature-set that we need to support.
Preliminary tests done by lupus/Paulo show that GdkPixbuf is over 2.5x
faster for our uses than IM is, though speed isn't a primary issue at hand
here (but nontheless should be considered).
Let it be known now that my preferred solution is #3, I'm ok with #2, and
very much against #1.
The fact remains that the Gnome port has to link against GdkPixbuf anyway
for a bunch of uninteresting reasons (dependencies of dependencies... Aaron
would have a field-day). If we link against IM and GdkPixbuf, well, we're
just increasing our binary's size and/or memory consumption. On Gnome at
least, GdkPixbuf is already guaranteed to be lying around in shared memory.
Seems a shame to not use it.
There are a few good arguments against using GdkPixbuf too, like duplicated
code/algoritms, etc... but I'll let my opponents conjure those up instead of
providing them with an axe to chop away at me with :-)
Dom
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
