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]