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).
> 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.
> Do you see other advantages for these functions to become visual
> operations (e.g. for interesting display targets that could deserve
> specific implementations) ?
Perhaps, but all the libgwt-specific functions can be accelerated if the
GWT objects have as a data item the visual they are running on,
and as for LibGGI rendering functions, the target-specifics can be separeted
into a display-gwt renderer.
> LibGWT ought to _replace_ all the drawing functions of a visual
> (referring to GGI libraries known by LibGWT) by its own specific routines
> (which, in turn, will call these functions, but probably on another visual
> and surely with a different clipping context).
On the one hand, creating new API functions like gwtDrawHline would
mushroom out of control if you go beyond the GGI core and start wanting
to use extensions on it. On the other hand, having two handles
associated with the gwt object (the GWT object handle for GWT ops and
the visual handle for GGI+extension ops) might be a bit unattractive.
I lean towards the latter. I mean:
ggiDrawHline(gwtGetWinVisual(mywin), 0, 0, 50);
...is not the ugliest thing I have ever laid my eyes upon.
> I've always asked me lots of questions on how to do this the right way in
> the GGI context - so I once again request some advice on how this should
> be done. Currently, LibGWT provides different drawing functions, like
> gwtDrawRectangle(win,x,y,w,h), which, to summarize, calls
> ggiDrawRectangle(win->vis,x,y,w,h) in a loop (surrounded by different
> clipping setups). But now, I'd really like some (hypothetical) LibGWT user
> to write code like this:
>
> gwtAttach(vis);
> ...
> ggiDrawRectangle(vis,x,y,w,h);
>
> And see the correct output (ie: a rectangle clipped by possibly
> overlapping windows).
How about this:
gwtAttach(vis);
mywindow = gwtCreateWindow(vis, ...);
/* if you've forgotton to know what the underlying visual is,
you can: */
underlying_visual = gwtGetGGIVisual(mywindow);
/* for simple use: */
gwtCrossBlit(vis2, mywindow, ...);
/* If you want full-blown rendering functions: */
gwtOpenVisual(mywindow);
/* This last does a ggiOpen("display-gwt", myvisual)
and a ggiSetMode to load the renderer. */
ggiDrawHline(gwtGetWinVisual(mywin), 0, 0, 50);
> Any idea, or do you think I should just try to code first, and talk after?
Don't ask me that, I have bad habits in that area :).
--
Brian
