On Tue, 27 Mar 2001, Brian S. Julin wrote:
>
> On Wed, 28 Mar 2001, Rodolphe Ortalo wrote:
> > Now, it's time to go back to the origin, and I'd like some external advice
> > to turn this library into a real GGI extension lib.
> >
> > There are two pretty distinct sets of functions in LibGWT:
> > 1- window-management related functions (let's call them gwtWindow*);
> > 2- in-window-drawing functions (let's call them gwtDraw*).
> >
> > Functions of set 1, gwtWindow*, deal mainly with LibGWT-specific data
> > (private extension data). Currently, they are offered in LibGWT as native
> > library functions. These functions could easily be turned into
> > extension-lib operations via the GGI extension lib system. However, I
> > don't really see yet how these functions could take advantage of several
> > display-specific variants.
>
> LibGalloc will help you do this, once we have targets that
> support it (basically, those will be KGI and maybe directX).
> What features I can see GWT using are hardware address
> translation apertures, sprites, and z-buffer (to assist
> clipping).
I'd say use libOVL for the hw-address translation port and sprites is
more efficient.
The z-buffer must be handled by your own as long as libbuf doesn't
exist.
> > So, the only real advantage I see in doing that
> > is that each gwtWindow*(gwt_window_t win, ...) would be replaced by
> > gwtWindow*(ggi_visual_t vis, ...). This would be more "GGI-conformant",
> > but is it worth the overhead penalty ?
>
> Probably no for some uses, and yes for others. I think you
> should keep the GWT object, but 1) provide a function to create a
> GGI visual for a window if desired, and 2) perhaps a way to
> transfer the objects between visuals and 3) a crossblit.
libBLT would be your friend, when it exists. I start working on it as
soon as libGAlloc is ready for it.
Both libOVL and libBLT use libGAlloc.
CU,
Christoph Egger
E-Mail: [EMAIL PROTECTED]
