Index: [thread] [date] [subject] [author]
  From: Brian S. Julin <bri@tull.umassp.edu>
  To  : Marcus Sundberg <mackan@stacken.kth.se>
  Date: Wed, 7 Jul 1999 11:27:49 -0400 (EDT)

Re: Got to be a faster way.

On Tue, 6 Jul 1999, Marcus Sundberg wrote:
> > If you do it, stick 'em in the display-file target.  It already writes
> > PPM, but could be made to read/write lots of other formats.  You'll need
> > to do something special for file-reading, e.g. a "-read" option which
> > loads the image into memory and then behaves like a read-only
> > display-memory target.
> 
> No thanks.
> That would be plain bloat and misuse of the dynamic loading mechanism.
> There are lots of tools to convert PPM images into whatever format you
> want,

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_.

> 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.

> 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?

The slew of loader functions do not have to, after all, be distributed
in the main tree -- we could move all of display-file to it's own package.
Plus, for certain simpler formats, people might finally be inclined to write
box put/get processing that doesn't require the entire file to be 
uncompressed in memory and recompressed.

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?

--
Brian

Index: [thread] [date] [subject] [author]