On Thu, 28 Oct 1999 [EMAIL PROTECTED] wrote:
> I am now converting it to a ggi extension, and I have a few implementation
> questions:
>
> 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, and just used the in_memory target if I
> 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...
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. Also,
what, if any, meaning would there be to Attach()ing ggiImg to a main visual?
> 2) I am making a lot of image tranform functions, should they be in ggiImg, or
> another extension, as if I use a ggi_visual they would work on any pixel
> buffer...
I would think transforms and loaders would go nicely together in the same extension.
Another alternative that someone thought up was to make the loaders into
targets instead of extensions -- but targets that only implement getBox/CrossBlit.
In that case, you would have something like this:
ggi_visual imgvis, memvis, newvis;
ggi_mode imgmode;
/* 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);
/* Now, to do transforms, we Attach the ggiImg extension. */
ggiImgAttach(memvis);
/* And say your ggiImg had a function to create a new ggiImg-attached
visual by shinking an existing one: */
ggiImgShrink(memvis, 2, 4, &newvis);
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);
If you want any help on understanding the extension mechanism, don't hesitate
to ask; I've written an automatic extension generator in case you weren't
aware of it.
P.S. Is anyone answering the webmaster account at ggi-project.org? Please
check your mail; I need to fix some broken links.
P.P.S. Were some list messages dumped yesterday, or am I just impatient?
--
Brian
