> On Thu, 28 Oct 1999 [EMAIL PROTECTED] wrote:
> > > Of course, you might want to be able to do it this way, too, if you
> > > want to reduce memory use by throwing away some data from the disk
> > > file:
> > >
> > >
> > > ggi_visual imgvis, memvis;
> > >
> > > /* display-file-jpeg sets up a visual representing the disk file. */
> > > imgvis = ggiOpen("display-file-jpeg:/tmp/bootie.jpg");
> > >
> > > /* For advanced loading features, Attach the ggiImg extension to the
> > > display-jpeg and you can get the img-file-jpeg extension sublib. */
> > > ggiImgAttach(imgvis);
> > >
> > > /* Let's say img-file-jpeg has a function to shrink the image while
> > > loading from disk. */
> > > ggiImgShrink(imgvis, 2, 4, &memvis);
> > >
> >
> > I think that an image-loader as a target would work, however it would be less
> > efficient then:
> >
> > ggiImgReadPNG(visual, FILE *file, ggi_sint x, y, w, h): This function could in
> > one step take the image to its destination visual(memory, display, ...),
> > wheras a target would need to be copied to its destination visual after
> > loading...
>
> No, the ggiOpen wouldn't load the image, just prepare an object
> to represent it. The disk file wouldn't get hit until you did the
> copying. So it would only be more efficient in that it's one less line
> of code in the app to use "ggiImgReadPNG", but it would result in
> a more streamlined API not to do this and to use a visual instead.
> I think that rejoins Andy's comment as well.
>
> It depends on how far you want ggiImg to go. If all you want is an simple
> image loader, that's cool, do it the obvious way. Personally I see the
> convenience of "being designed for GGI" as the only reason someone would use
> ggiImg over libpng or over just opening a pipe from "/usr/bin/convert" and
> sucking data themselves. Not much value added to a loader. But if you want
> now or in the future to be able to do efficient disk-to-disk or
> disk-to-memory in-stream transforms and format conversions that don't run
> off with all your memory and swap space like the pnm stuff does, then why
> not make the API to do so graceful and intuitive?
>
>
> --
> Brian
I agree, I was looking at the ggiOpen the wrong way. I am going to have to
work out a progressive loading scheme(most images are loaded progressively
these days via a stream(http...)), but I am sure it wont be much different
then how I currently do it, just moving some counters into another
structure...
-Kor Grey <[EMAIL PROTECTED]>
