Subject: Re: Linking against libjpeg ?
From: Dom Lachowicz (cinamod@hotmail.com)
Date: Thu Apr 19 2001 - 18:47:27 CDT
> >Having one
> >guaranteed format for import (png) and then using system
> >services (translators on BeOS, imaging library on QNX etc)
> >would be my recommendation.
>
>Insofar as we have adequate imaging support on both of those platforms, the
>Right Thing is clearly to use them. Has anyone disagreed publicly or
>privately?
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. If we use
system services, even better.
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?
>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...
> >If I had a thing to say about it, I would say make it a
> >loadable module (and consequently make loadable modules
> >work properly) but don't force it to be present.
> >
> >AbiWord ... 3M and growing fast
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.
>I'd still love to see stats on how much of that bloat is due to:
>
> - more file formats
> - more localizations
> - more encodings
>
>Many of those could certainly be externalized when we have loadable modules
>done right, but I'm not sure which ones are the most heavyweight.
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.
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.
[dom@psk-60 xp]$ wc -l ap_EditMethods.cpp
6651 ap_EditMethods.cpp
[dom@psk-60 xp]$ wc -l ap_*Label*.h
6677 total
So we're looking at similar orders of magnitude.
Dom
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
This archive was generated by hypermail 2b25 : Thu Apr 19 2001 - 18:47:54 CDT