From: Andreas Beck <becka@rz.uni-duesseldorf.de>
  To  : ggi-develop@eskimo.com
  Date: Fri, 23 Jul 1999 20:17:46 +0200

Re: Got to be a faster way.

> > There are lots of tools to convert PPM images into whatever format you
> I have found most of those tools to be very poorly written -- e.g.
> I cannot convert/rotate/scale/etc a PGM scan of an 8.5x14 sheet of paper 
> to some formats on a machine with 32 M of RAM and 75M of swap because 
> they run out of _memory_.

Yes. I have to second that. I have seen scanning fail due to similar
reasons, just because my CGI scripts are converting to a more
windows-friendly format (TIFF) on the fly.

> > and display _targets_ are hardly the right place to load images.

> We've talked about printers as display targets, why not file formats?  I
> think it would be handy to be able to open a display-file
> and a normal display and have snaps of what you're doing dumped into
> files every 20 seconds or so, better so if I could avoid having 
> several hundred uncompressed PPM data files on my hands afterwards.

That can be done. From targets.txt:

Additional Options:

-flushcmd="command_to_execute"
...
The file target can be used to generate movies from running LibGGI
applications. To do this, set -flushcmd to a shell command to execute
at the times given by one of the two other parameters. This looks typically
like "ppmtogif foo.ppm >foo.%04d.gif". The command is passed through a
printf which has the current count of saved frames as an argument (or
rather as 10 arguments to allow a few more complex commands).

> > What is needed, not only for LibGGI, is an image loading library which:
> > a) is not dependent on X or any other graphics system.
> > b) uses GGI style dynamic loading to handle different image formats.

> Aside from the "not only for LibGGI" what's the big difference between
> writing a "GGI-style" dynamic image code loader, and having display-file 
> generate a suggest string based on file extension/magic number and 
> dynamically load functions for a given format?

This is possible, but as we can separate it out, I'd rather like it, if that
would be done. GGI is a nice project, but we are not the hub of the world,
so it might be nice to have a really generic image loader.

Of course using LibGGI is very tempting, as it is very elegant to just load
images into a mem visual, but I'd as well prefer, if one could use it
standalone.

> Totally aside from this point -- anyone thought of how two back-buffering
> targets could share the display-memory they use rather than each opening 
> its own?

I don't get you on that ... could you describe that further or rephrase it ?

CU, Andy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =