nanogui: rearchitecture discussion
Subject:
rearchitecture discussion
From:
Greg Haerr ####@####.####
Date:
20 May 1999 19:56:56 -0000
Message-Id: <01BEA2C6.76C9BEF0.greg@censoft.com>
>
> Out of interest, here is the allegro structure. As you can see, it's quite
> a bit more advanced, including information about whether to clip it, where
> to clip it (relevant to its origin), allows it to be used for the hardware
> itself, provides for sub-bitmaps, etc. At least some of these features are
> probably useful.
Yes, defintely. The Allegro BITMAP struct is actually at the level of
my SCREENDEVICE struct. It is used as the first argument for *all* drawing
routines. As I mentioned, I think a complete rearchitecture would be a good idea
here, and was for a while proceeding down that tack.
My BITMAP structure, possibly inappropriately named, was
a suggestion for bitplane data only, not enough to be used as a first
argument for the draw functions.
Back to the allegro architecture for a moment, I was thinking that
ultimately the structure should be named GC for our project. In addition
to clipping and all appropriate proc ptrs for the drawing functions, it should
contain the fg and bg colors set, etc that currently are global vars in srvdraw.c.
Thus, the structure is really a graphics context, where *all* the contextual information
about a graphics situation is contained in one place. This includes whether
it's a memory or device context. It would be the first parm in all graphics calls, and
the "driver" level that I've currently implemented comes up one level for the
screen stuff only. The kbd and mouse drivers remain as drivers. System-specific
stuff like framebuffer vs ELKS remains at the new driver level. Get it?
But, so far, noone has tried to port any X program to nano-X anyway.
>
> I agree.
I ask again, if anyone's got some small X programs that do something
graphically useful, it'd be nice to see them...
