nanogui: rearchitecture discussion
Subject:
RE: rearchitecture discussion
From:
Greg Haerr ####@####.####
Date:
21 May 1999 17:47:14 -0000
Message-Id: <01BEA37F.75501830.greg@censoft.com>
> > 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
