nanogui: Thread: rearchitecture discussion

> 
> 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...

On Thu, 20 May 1999, Greg Haerr wrote:
> 	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.

I'll let you do that, as you seem to know what you're doing much better
than I ;)

> 	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.

I see, good idea.

> 	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

Interesting idea. Are we going to always preserve the GC data (so the
server can redraw automatically on expose rather than having to ask the
client to do it)? One way we could possibly avoid this is to not store the
bitmap data in the structure but a pointer to it, and whenever we need
some memory for a new bitmap, we search through all the GCs for any which
have bitmap data, but are not currently visible, and if the bitmap is
larger than we need we can detach it from that GC (set the bitmap pointer
to NULL), and reuse the space. If a window is only partially occluded, the
bitmap data doesn't get reused (and redrawing will be handled by the
server). We could also add some intelligent algorithms for deciding which
bitmap space to reuse next, based on how much larger the bitmap is than we
want (ie. if we want 1KB of space, and there are two bitmap spaces
available for use, one 2KB in size and one 300KB in size, use the 2KB
one), how long it is since the bitmap was last used, and how much total
system memory is free for use. When a window is exposed, we check whether
the bitmap data pointer is NULL, if it is, we reallocate the space and
send an expose event to the client, if it isn't, we just redraw it
ourselves without the client ever needing to know about it.

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

> > 	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
> 
> Interesting idea. Are we going to always preserve the GC data (so the
> server can redraw automatically on expose rather than having to ask the
> client to do it)? One way we could possibly avoid this is to not store the
> bitmap data in the structure but a pointer to it, and whenever we need
> some memory for a new bitmap, we search through all the GCs for any which
> have bitmap data, but are not currently visible, and if the bitmap is
> larger than we need we can detach it from that GC (set the bitmap pointer
> to NULL), and reuse the space. If a window is only partially occluded, the
> bitmap data doesn't get reused (and redrawing will be handled by the
> server). We could also add some intelligent algorithms for deciding which
> bitmap space to reuse next, based on how much larger the bitmap is than we
> want (ie. if we want 1KB of space, and there are two bitmap spaces
> available for use, one 2KB in size and one 300KB in size, use the 2KB
> one), how long it is since the bitmap was last used, and how much total
> system memory is free for use. When a window is exposed, we check whether
> the bitmap data pointer is NULL, if it is, we reallocate the space and
> send an expose event to the client, if it isn't, we just redraw it
> ourselves without the client ever needing to know about it.
> 

	These are very valid optimization ideas, but they come with a cost,
sometimes large.  The cost is the extra memory required to keep copies of the
bitmap data for all the GC's.  Also, a GC may be used quite a few times, so only
the last bitmap data can be saved.

	In any case, a possible way to implement your idea is to have the GC's
hold a flag bit, GC_SAVEBITS, which would allow the programmer to tell
the server whether to redraw and hold the expose event...

Greg