On 8 Mar 2000, Thomas Mittelstaedt wrote:
> I have an instant need to be able to draw Arcs, RoundRects and
> Polygons etc. So, if somebody of the GGI project can give me
> guidance, I can jump right into integrating libxmi, since libggi2d
> just does not work. I already installed libxmi. There are a few
> customizations that they mention in the main header xmi.h.
Overall, it seems to me that libxmi should be directed so as to use
LibGGI's "DirectBuffer"s to access the framebuffer. Alternatively,
you could use ggi{Draw,Put,Get}Pixel directly... (Maybe it's simpler.)
> At installation time one can redefine 3 things:
> i) Define MI_PIXEL_TYPE at installation time
> ii) MI_CANVAS_DRAWABLE_TYPE can be redefined to describe what a Pixmap
> should be.
> iii) MI_DEFAULT_MERGE2_PIXEL can be set to a different algorithm than
> the Painter's, when pixels are applied to the 'canvas'.
It don't know DirectBuffer or LibGGI basic types well-enough to direct
you. But I have the feeling that Andreas or Marcus could easily tell you
what these macros should be... :-) (LibXMI may need to be recompiled
several times to generate the second stage for 8bpp, 16bpp, etc. Or maybe
LibGGI can take care of this...)
IMO, the drawable type is an array of MI_PIXEL_TYPE (linear framebuffer
abstraction). Like the default.
MI_DEFAULT_MERGE2_PIXEL is primarily useful for transparency management
(alpha channel). In a first step, you can surely use the default settings
(a new pixel replaces an old one).
> Is that enough to get basic drawing functionality working together
> with GGI? Using cross-blitting from memory could also take care of
> clipping.
I think it is enough.
> So what are the plans? I have to do something, now!!
:-)) Fiddle with libxmi second stage and try to set things so that libxmi
uses libggi DirectBuffers...
But that was just an idea you know...
Rodolphe
