Subject: Re: Linking against libjpeg ?
From: Paul Rohr (paul@abisource.com)
Date: Thu Apr 19 2001 - 20:35:56 CDT
At 07:47 PM 4/19/01 -0400, Dom Lachowicz wrote:
>I disagree as to the functionality we should be looking for from this
>imaging library. I just want a lib that takes a file/byte array and turns it
>into a pretty picture on my screen. I don't need or want some lib built-in
>to my program specifically to do conversions. The Gimp, Imlib2, and IM's
>convert do that for me as stand-alone apps. All I want (and all I ever want
>checked into the tree) is something that loads and draws images to the
>screen. If IM is to be that lib, great. No complaints from me.
AFAIK, there ain't no such animal, unless you restrict yourself to a single
platform. Anyone can do file format conversions in an XP way, but putting
the bits on-screen is inherently platform-specific, no?
The proposal is to do 98% of the work in XP code (the conversions), then
have a little bit of platform code (which already exists, BTW) to get it
on-screen.
>If we use
>system services, even better.
Agreed.
>I prefer this to be done through system services. <sarcasm>If people
>disagree, I'm voting for a GTK+ only port of abi to every platform to also
>save development time</sarcasm> Here it really makes sense to use the tools
>given to you. Unless I'm horrendously mistaken, a key idea behind Abi is to
>use what's available natively in your implementation. If you don't have
>something natively, we'll supply it to link against (zlib, libpng, iconv). A
>pretty-decent interface and makefile system has been set up for people to do
>exactly this. Why do we want to abandon this now for images?
We don't. We just need an interface so that Hub can add libjpeg for
platforms that need it (Win, for one), and Thomas can omit it for platforms
that don't (ie, his).
On this one, you're preaching to the choir, brother.
>>Are you saying that our XP support for BMP is:
>>
>> a. redundant on those platforms (system services Just Work) or
>> b. unwanted on those platforms (nobody cares about BMP there)?
>>
>>In either case, I'd be more than happy to see you (or someone else)
>>refactor
>>the code and/or makefiles so that it's easy for platforms to choose whether
>>to compile them in or not.
>
>XP BMP is rednundant for some, essential for others. It's a perfect example
>of my "#1) Roll our own" implementation that I'm not a fan of at all...
More violent agreement. What's your point?
>Loadable modules will hopefully alleviate some things here. 3M is really not
>all that bad though, considering the functionality we're getting. Neither is
>a 15 minute compile time. How long do you think it takes to compile OO or
>Word? Hell, we compile faster than it takes for OO to load on my box.
Please don't compare us to those pigs. One of these days Thomas is going to
be able to do more than hint about the kinds of devices he's got AbiWord
running on. In some situations, 3M is horrendously large.
>Localizations and encodings add up. There is no reason for me to have polish
>strings and XPMs linked with my binary. gettext() or a similar system
>(Java's MSGFormat comes to mind...) is good for this sort of thing.
We all agree that moving them out will help. We disagree on the specific
mechanism used, and to date nobody's had the time to address each other's
concerns. All I was wondering was how svelte a binary we'd get if we cut
back to en-US only. Is that what's big, or is it the encodings, or is it
the mere fact that it's an X application?
>File formats also add up. But let's see what we're talking about:
>
>[dom@psk-60 xp]# wc -l ie_imp_*.cpp
>11061 total
>
>That's including the 4500 LOC needed for TXT, RTF, and ABW which we will
>never split into optionally-loaded plugins (RTF and TXT are needed for
>clipboard stuff). This also includes all of the absolutely necessary IMP/EXP
>framework *and* the graphic loaders.
>
>[dom@psk-60 xp]# wc -l ie_exp*.cpp
>12840 total
>
>with a similar mention about TXT, RTF, and ABW as above.
Methinks you left out a few little libraries called wv et al. ;-) You may
not have them in *your* binary, but they're statically linked in mine.
>[dom@psk-60 xp]$ wc -l ap_EditMethods.cpp
>6651 ap_EditMethods.cpp
Yep. These stay.
>[dom@psk-60 xp]$ wc -l ap_*Label*.h
>6677 total
Jeff does enough macro magic that these get included several times, so it's
a bit disproportionate.
Thanks,
Paul
This archive was generated by hypermail 2b25 : Thu Apr 19 2001 - 20:28:37 CDT