> * Andreas Beck ([EMAIL PROTECTED]) [000203 13:09]:
> > > > Hmm - I'd like it better, if it would read only P?M and use ppmtools to
> > > > convert any other format as required.
> > 
> > > I want to have reading some different file-formats and not only one.
> > > That's why I hack the file-target.
> > 
> > This is a misconception IMHO.
> > 
> > The idea of the ppmtools is to finally put an end to reinventing the picture
> > loading and saving wheel for every program/lib/whatever.
> > 
> > As long as you can load/save ppms (which is trivial) you can load/save any
> > format by just piping the output through the appropriate ppmtools.
> > 
> > LibGGI is intended to be lightweight, and I'd like to keep it this way.
> 
> Compile-time options and existing dynamic libraries can take care of this,
> but I think ppms can solve it too (see below).
> 
> > So what you should do is to use ppmtools to convert other filetypes to/from
> > ppm on the fly.
> 
> I almost agree, let me just clarify some points. I think it should be
> completely transparent. What I think you're suggesting, and what I would
> suggest, is to have this conversion built in the file target: when opening
> something that is not a ppm, file-target tries to find the correct ppmtool
> and spanws it in the background and gets the ppm through a pipe or whatever.
> The user is never aware of the conversion.
> 
> My only con to this option is that its not really efficient both in terms of
> speed (spawns process, reads file, pipe file...) and memory (at some point
> two copies of the translated file have to be in memory, one for each pipe
> end --- and that can be a *real* problem in systems with relative with low
> memory, since ppms are not really good in saving memory --- swap, swap...).
> 
> Ideally, some very common types could be built in. We have libjpeg.so (I
> think we even have libtiff.so), so there's almost no overhead in having
> jpegs. For GIFs, use the ppmtools scheme above (avoid legal problems). What
> I'm really against is implementing a complete jpeg reader from scratch, for
> example.

It is more fficient to use libpng, libjpeg, libtiff, etc. Then it would be to
pipe through conversion programs. As a last ditch effort a call to convert
could be used(as in imlib), but normally a dlopen of a image-loader lib(again,
as in imlib) is very efficient. I have a small program that dlopens libpng and
displays a png image using GGI, but I did not implement it as the file-target
:(
Its really too bad that imlib isnt target independent, we should have
something similar in GGI. I think we also really need some bindings into
Hermes(efficient pixel-format conversion library).

> HE WHO SACRIFICES FUNCTIONALITY FOR EASE OF USE
> LOSES BOTH AND DESERVES NEITHER
"Those who desire to give up Freedom in order to gain Security, will not have,
 nor do they deserve, either one."  -Thomas Jefferson

 -Adam Scislowicz([EMAIL PROTECTED])

Reply via email to