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
