Hi !
> > 1) I am currently using a proprietary struc (ggiImg...) which contains
> > width, height, pixelformat, data_layout, and data... would it be better
> > if I used a ggi_visual instead,
Yes. That's what I usually do. I can contribute PPM/PGM/PBM loader code (yeah,
I know it's trivial :-). that already works this way.
However it is usually not required to store extra metadata when you use a
visual, as width, height and depth are already encoded. Thus an extension seems
a bit like overkill (I'd just make a regular lib). However a few extra fields
might come in handy for stuff like transparency. So an extension might be
justified.
> > want to do off-screen work, that way they could use the image transforms in
> > a doublebuffer, or offscreen, etc w/o be making a bunch of special cases in
> > my functions...
Yes. This is why I like the memory target approach for these situations.
> You can add any extra members you need to add to a visual structure with
> the extension mechanism, so it should be more than possible to use a
> memvisual instead. The tacky part is the way they have to be accessed. From
> within your extension functions, you should have no problem accessing the
> extra structure with a simple macro, but from the application side, the extra
> structure members have to be accessed through a libggiImg API function call.
Which is good, as it is an abstraction layer that ensures interoperability
when things get upgraded.
> Also, what, if any, meaning would there be to Attach()ing ggiImg to a main
> visual?
That's the point. Such a thing would be more a kind of "companion library"
than an extension. Maybe you would rather use a struct that contains a visual
pointer for storing the image representation.
> Another alternative that someone thought up was to make the loaders into
> targets instead of extensions -- but targets that only implement
> getBox/CrossBlit.
This is pretty elegant, as the point where the file loading kicks in is not
so easily covered by an extension which needs to be attached to an existing
visual , but a target which can create a new visual.
> /* display-file-jpeg sets up a visual representing the disk file. */
> imgvis = ggiOpen("display-file-jpeg:/tmp/bootie.jpg");
> ggiGetMode(imgvis, &imgmode);
> memvis = ggiOpen("display-memory");
> ggiSetMode(memvis, &imgmode);
> /* code in display-file-jpeg target copies data into a memvis */
> ggiCrossBlit(imgvis, 0, 0, imgmode.virt.x, imgmode.virt.y, memvis, 0, 0);
This is surplus IMHO. I'd load the image into a memvisual at ggiOpen()-time,
so you have all operations handy.
> P.S. Is anyone answering the webmaster account at ggi-project.org? Please
> check your mail; I need to fix some broken links.
Hmm - I haven't heard from Steve for a while ... oh - wait ... AFAIK there
was some strange mail system trouble on ggi-project.org. Eman fixed that
recently. You might need to resend.
CU, ANdy
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
