nanogui: rearchitecture discussion


Previous by date: 21 May 1999 11:21:44 -0000 Truecolour, Pseudocolour, Alex Holden
Next by date: 21 May 1999 11:21:44 -0000 Re: Questions?, Alex Holden
Previous in thread: 21 May 1999 11:21:44 -0000 rearchitecture discussion, Greg Haerr
Next in thread: 21 May 1999 11:21:44 -0000 Re: rearchitecture discussion, Greg Haerr

Subject: Re: rearchitecture discussion
From: Alex Holden ####@####.####
Date: 21 May 1999 11:21:44 -0000
Message-Id: <Pine.LNX.4.04.9905211159360.706-100000@hyperspace>

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


Previous by date: 21 May 1999 11:21:44 -0000 Truecolour, Pseudocolour, Alex Holden
Next by date: 21 May 1999 11:21:44 -0000 Re: Questions?, Alex Holden
Previous in thread: 21 May 1999 11:21:44 -0000 rearchitecture discussion, Greg Haerr
Next in thread: 21 May 1999 11:21:44 -0000 Re: rearchitecture discussion, Greg Haerr


Powered by ezmlm-browse 0.20.