Subject: Re: Linking against libjpeg ?
From: Dom Lachowicz (cinamod@hotmail.com)
Date: Thu Apr 19 2001 - 20:51:57 CDT
Paul 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?
Yes there are, but I won't go too deply into that. AFAIK, IM or GdkPixbuf
has the ability to turn its munched data into a RGBA buffer. Unix/Gnome,
QNX, and Win32 post this RGBA data to screen. Mac and Be might too, but i
haven't looked.
>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.
Yup. This one LOC still stays. All we get rid of are all of the code (which
is p-spefic anyway) that turns a UT_ByteBuf into a png_info_ptr. Win32 still
calls StretchDIBits(...) but the only thing that changes is where it gets
those RGBA bits from.
>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.
If we wish to compete against them in any sense of the word, we must compare
ourselves to them whether we would like to or not. 3M might be horribly
large for some situations. So do we now not put any new features in or fix
bugs because it adds a few KB? I'm confused.
>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?
A little from column "A", a little from column "B"... We're not bloated from
translations, though it does add overhead. We're getting larger primarily
because we're doing a *lot* more as of-late. Features require KB.
>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.
Yeah, but that doesn't hurt my point much. wv adds a lot of overhead.
Modules will certainly help. Who's going to do them? Dunno.I laid a basic
framework...
Thanks,
Dom
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
This archive was generated by hypermail 2b25 : Thu Apr 19 2001 - 20:52:05 CDT