From: becka@rz.uni-duesseldorf.de
  To  : mailing list GGI <ggi-develop@eskimo.com>
  Date: Sat, 19 Sep 1998 21:14:25 +0200 (MEST)

Who restructured DirectBuffer ?

Hi folks !

I'd really like to know, who restructured the directbuffer stuff ... ???

I have just checked it out again, as I wanted to re-accelerate the crossblit
function.

I do _not_ like the new scheme, because I think it misses some important
points:

typedef struct {
        uint32          type;
Hmm - not sure if this is needed, but ... o.k.
	...
} ggi_directbuffer;

typedef struct {
        int             depth;
o.k.
        int             size;
o.k.

        ggi_pixel       red_mask;       /* Bitmask of red bits */
        ggi_pixel       green_mask;     /* Bitmask of green bits */
        ggi_pixel       blue_mask;      /* Bitmask of blue bits */
        ggi_pixel       alpha_mask;     /* Bitmask of alphachannel bits */

        ggi_pixel       clut_mask;      /* Bitmask of bits for the clut */
        ggi_pixel       fg_mask;        /* Bitmask of foreground color */
        ggi_pixel       bg_mask;        /* Bitmask of background color */
        ggi_pixel       texture_mask;   /* Bitmask of the texture (for
                                           textmodes - the actual character)

These I don't like. This makes the struct likely to grow beyond limits.
The number of possible bits in a pixel is rather limited to 32 or 64.
The number of possible uses is not or at least much less limited. 
Thus I'd like some scheme like

	int ggi_bitmeaning[MAXNUMBITS];

This ints should split up into several fields that allow to extract the
meaning of each bit. Something like 
ggi_bitmeaning[0]=BM_COLOR |BM_RED  |BM_BIT(0)
ggi_bitmeaning[1]=BM_COLOR |BM_RED  |BM_BIT(1)
ggi_bitmeaning[2]=BM_COLOR |BM_GREEN|BM_BIT(0)
ggi_bitmeaning[3]=BM_COLOR |BM_GREEN|BM_BIT(1)
ggi_bitmeaning[4]=BM_COLOR |BM_BLUE |BM_BIT(0)
ggi_bitmeaning[5]=BM_COLOR |BM_BLUE |BM_BIT(1)
ggi_bitmeaning[6]=BM_ATTRIB|BM_BLINK
ggi_bitmeaning[7]=BM_ATTRIB|BM_ALPHA|BM_BIT(0)

The idea is, that we can add additional flags/modes without problem.
In the current scheme the struct would change thus causing binary
incompatibility.
If we give 8 bits to the bit identifier, 8 to the subtype-id, and 8
to the type id (see above), we still have 8 bits left to account for
completely new modes.

Note, that both the old and the new scheme require quite some parsing
to really _adapt_ to what they say. The old one requires, that you
extract the number of bits and the shift in order to be able to quickly
assemble the right number. And this still assumes, that noone builds
a sick card with something like RGBARGBARGBARGBARGBA ...
The new scheme ain't much better in that respect, too.

        uint32          flags;          /* Pixelformat flags */
#define GGI_PF_REVERSE_ENDIAN   0x01
#define GGI_PF_HIGHBIT_RIGHT    0x02
#define GGI_PF_HAM              0x04
#define GGI_PF_EXTENDED         0x08

This is by _no_means_ appropriate. The old scheme had a much more
sophisticated description of what swapping operations
(note, there is not only 12345678 and 87654321 endianness, but also
 weird things like 34127856 and such ...) and alignment are required.

And then for the thing I miss most: my beloved enum, that allowed to
decide whether a mode is known or not in a split second.

This is what _most_ existing programs will want to do. They have some
optimized renderers for the common modes. And if the directbuffer
matches one of those known modes, the optimized renderer is used.
If not, we fall back to LibGGI drawing primitives.

So could we please add back at least the swap,align and setup_enum
parts ? Or is there any reason not to ?

I'd like to see the other things changed, too, but they should be discussed.
I do not want this to be change to-and-fro all the time.

CU, ANdy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =