Index: [thread] [date] [subject] [author]
  From: Andrew Apted <ajapted@netspace.net.au>
  To  : ggi-develop@eskimo.com
  Date: Mon, 13 Jul 1998 13:59:30 +1000

Re: Frames...

Alexander Larsson writes:

>  So i decided to implement Frames in libggi according to 2.9 in
>  libggi-issues.txt. I have just begun looking at it, thinking i could
>  start with the X-target, but i immediately found a problem that can
>  possible break a lot of things..
>  
>  The linear libraries does a lot of stuff like this:
>   
>  *(((uint16 *)LIBGGI_FB_LINEAR(vis))+y*LIBGGI_FB_WIDTH(vis)+x)=col;
>  and 
>  *pixel=*(((uint16 *)LIBGGI_FB_LINEAR(vis))+y*LIBGGI_FB_WIDTH(vis)+x);
>  
>  This is all nice and dandy with the current implementations, but
>  according to the following from libggi-issues.txt it is wrong:
>  
>    o  Three additional functions are required, to switch between these
>       frames for drawing, reading back (ggiGet*) and for displaying,
>       e.g.:
>  
>    o  ggiSetDisplayFrame(vis, int frameno);
>  
>    o  ggiSetWriteFrame(vis, int frameno);
>  
>    o  ggiSetReadFrame(vis, int frameno);

Yep.

>  This gives a problem. I must have to pointers to the linear buffer, one for 
>  reading and one for writing to make this possible.
>
>  This calls for a change in ggi_info_fb, split 'linear' into
>  linear_read and linear_write. Also the LIBGGI_FB_LINEAR(vis) macro
>  needs to be split into two.

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.

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.

    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)

    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.

So folks, how does this sound ?

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

Cheers,
_____________________________________________  ____
                                               \  /
  Andrew Apted   <andrew@ggi-project.org>       \/
  

Index: [thread] [date] [subject] [author]