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]