From: Alexander Larsson <alla@lysator.liu.se>
  To  : ggi-develop@eskimo.com
  Date: Mon, 13 Jul 1998 14:43:29 +0200

Re: Frames...

> It was decided that ggi_info_fb should be removed, and the directbuffer
> stuff should be used instead.  So yeah the LIBGGI_FB_* macros will need
> replacing.
 Ok, this sounds smart to me.

> 
> Here's what could be done :
> 
>     1. Add the following to ggi_info:
>           
>           ggi_directbuffer *read_db;
>           ggi_directbuffer *write_db;
> 
>        (Remember each frame has it's own directbuffer).  
>        
>        These two fields would be updated by ggiSetReadFrame() and
>        ggiSetWriteFrame() respectively -- by scanning through the
>        directbuffer list (ggi_info.db) and finding frame N.

 Ok, this list (ggi_info.db) isn't very well documented... Does it contain 
only one db for each frame in order 0 upto numframes-1 or can it also contain 
other buffers (like z-buffers and so)? If so, how do i scan it and find frame 
N?

Another related question: which buffer does ggiDBGetBuffer return? I suppose 
it returns the first frame (0) and you have to follow the next pointer to get 
to the next frame. Also these are guaranteed to be of the same size and layout?

>     2. LIBGGI_FB_LINEAR is replaced with:
> 
>           #define LIBGGI_PLB_READ_FRAME(vis)  \
>                   (vis->info.read_db->buffer.pixellinearbuffer.read)
>           #define LIBGGI_PLB_WRITE_FRAME(vis)  \
>                   (vis->info.write_db->buffer.pixellinearbuffer.write)
>    
>        (with other defines for non PLB buffers)

 Ok, seems ok.

>     3. LIBGGI_FB_WIDTH & LIBGGI_FB_HEIGHT are replaced with:
> 
>           #define LIBGGI_PLB_WIDTH(vis)  \
>                   (vis->info.write_db->buffer.pixellinearbuffer.size.x)
>           #define LIBGGI_PLB_HEIGHT(vis)  \
>                   (vis->info.write_db->buffer.pixellinearbuffer.size.y)
> 
>        (with other defines for non PLB buffers)
> 
>     4. Similiar changes for LIBGGI_FB_BPP et al.
> 
 Good.

> So folks, how does this sound ?
 I'm still a bit unsure about the exact definition of these different 
directbuffers... Please enlighten me.

> >  This will mean binary incompatibility...
> 
> LibGGI binary compatibility is something we *definitely* shouldn't worry
> about right now IMHO.  It is still very much a moving target (both
> externally and internally).
> 
 I Agree, but if we start breaking things now we should 'break it all' as soon 
as possible to have fewer problems later.
 
/ Alex