Subject: Re: image support (was Re: Core-dump during startup on AIX-4.3.2)
Nathan@unos.net
Date: Thu Mar 02 2000 - 22:01:57 CST
Okay, there's something I'm not getting here. I originally asked the
question to try and determine what was and was not acceptable in terms of
external libraries. So the first thread runs like this:
On 2 Mar, Paul Rohr wrote:
> At 02:15 PM 3/2/00 -0600, Justin Bradford wrote:
>>I recommend we use gdk-pixbuf as a model. Basically, we do the simple
>>formats (ie. BMP) ourselves and link to libs for the hard ones (ie. JPEG).
>>
>>libjpeg, libungif, libtiff, etc, should be pretty portable. The ungif
>>source might small enough to just copy, too...
>>
>>It's not much code and it avoids large lib dependencies.
>
> Yeah, I like this approach, too:
>
> - it's what we're doing already with libpng,
> - it allows us to control the footprint of each library, and
> - having worked with libjpeg in the past I know it's eminently portable.
In other words: link against *several* external libraries, and port
where they're not available. Okay, I can live with that, it makes my
life easy because I don't have to write my own functions.
The next thread runs like this:
>>However, one other suggestion: can we make these image importers
>>subclassable to platform specific implementations? For instance, with the
>>gnome version, I'm certain we'd like to just swap this code out for the
>>actual gdk-pixbuf implementation.
>
> That's a very good idea, and should definitely be a design constraint for
> whatever switching mechanism we come up with.
>
> Essentially, we'd have an XP factory API which produces a converter which
> can convert a blob of image data in some specific format to PNG. The source
> trees we release would have XP implementations for every file format we
> support, but somehow (hand wave, hand wave) each platform would be able to
> override the factory to generate simpler stubs which just drive existing
> platform-specific image conversion services. The makefiles for that
> platform would decide which of the standard libraries to build and/or link,
> as needed, to create a single full set of converters.
Now we're saying: Hey, AbiWord has it's *own* *native* *built-in* *XP*
converters for *each* format *to* PNG. This simplifies manipulation
internally, because we're always manipulating PNG (actually, we'll
probably always be manipulating a raw pixmap, but there you go).
So are we suggesting that we rip the code out of libjpeg, libgif,
libtiff, etc, and *include* them as an integrated part of AbiWord?
'Cause if we do this, I don't see the need to link against
platform-specific libs. Who *cares* if BeOS (just as an arbitrary
example) has a really, really spiffy jpeg-loading system call? Our
*built-in* jpeg-loading call (which we stole from libjpeg) already
works, and it's doubtful that the BeOS one works "better" enough to
justify the "hand wave, hand wave" magic described above.
Then, of course, we have a *third* thread, which runs like this:
On 2 Mar, Paul Rohr wrote:
> At 07:48 PM 3/2/00 -0600, Justin Bradford wrote:
>>> WHY do we want to invent the wheel rather than simply use
>>> ImageMagick? It's available for all/most (I don't think there is a QNX
>>> port) of the target platforms and it already abstracts out image stuff
>>> for us, especially using all the libraries.
>>
>>First, I don't think the abisource people want to use it, so it's really
>>pointless to argue it.
>
> We still fantasize about keeping AbiWord lightweight enough to run in pretty
> tightly constrained environments (like settop boxes, Crusoe pads, old 486s,
> etc.). Those just aren't scenarios where ImageMagick's memory footprint
> sounds appropriate.
>
> No matter how cool ImageMagick is, it's overkill for us.
So we *don't* want to link against ImageMagick, but we *do* want to
link against a "native" library, if one exists?
I just don't really understand what we're talking about. Blame it on
the decaf...
I was kinda thinking we'd have a set of XP stubs, like "load_jpeg()",
all of which would have platform-specific implementations. So, on
Linux/x86 the "load_jpeg()" function could be a wrapper for a call to
libjpeg (if we have it) or ImageMagick (if we have it). On BeOS
(arbitrarily again, since I don't actually *know* anything about BeOS)
the "load_jpeg()" function could be a wrapper for a system call.
Regardless, "load_jpeg()" has a standard API, so it can be called from
all our XP code without breaking anything.
The big question is still: "What do we do on architectures/platforms
where we don't have a library?" We either have our own built-in
function or we *require* libraries by platform. If we have our own
built-in function, though (which I'm not against), I don't see why we
need the ability to link in platform-specific functions. I just don't
see what it gains us.
Anyway, I'm glad to keep talking. It'll be two weeks before I actually
have any time to work on it, so if we can figure out what we're doing
*first*, that'd probably help in the long run... >)
Oh, and I'm totally willing to go with the consensus, just as soon as I
figure out what it is... >)
Have fun,
Nato
This archive was generated by hypermail 2b25 : Thu Mar 02 2000 - 22:04:07 CST