From: Marcus Sundberg <mackan@stacken.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Sun, 20 Sep 1998 16:11:08 +0200

Re: Who restructured DirectBuffer ?

becka@rz.uni-duesseldorf.de wrote:
> 
> Hi folks !
> 
> I'd really like to know, who restructured the directbuffer stuff ... ???

Well, it was me who actually commited it.
Me and Andrew considered that rather than waiting for you to get back,
it was better to hack away so we got _something_ done, and discuss the
changes when you got back.

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

Ok, we'll have to try to sort this out then.

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

BM_BIT() would be the bit number, right? What about fields with more
than 8 bits?

My suggestion is that we keep the simple fields for
red/green/blue/alpha/clut,
and let the rest of the fields be defined bu ggi_bitmeaning. (The above
five
would ofcourse be there too)

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

You do not need to know the number of bits, only the mask and shift.
(Look at this from color-generic:
#define DOSHIFT(val, shift)  \
        (((shift) >= 0) ? (val) << (shift) : (val) >> -(shift))
pixel = (DOSHIFT(col->r, ck->red_total - 16) & 
                 LIBGGI_PIXFMT(vis)->red_mask)   |
        (DOSHIFT(col->g, ck->green_total - 16) & 
                 LIBGGI_PIXFMT(vis)->green_mask) |
        (DOSHIFT(col->b, ck->blue_total - 16) & 
                 LIBGGI_PIXFMT(vis)->blue_mask);

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

This is supported by my scheme, provided that the the bits
are in the same order in the pixel and in the field.

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

Well, don't you think that the remaining 2^28 possible combinations
of flags can cover all those? Having well defined and documented flags
that describe the format is better than the (IMHO) obscure swap entry
we used to have.

> and alignment are required.

Before removing that I asked if anyone could give me a case when
the alignment field is useful. Can you?

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

Oh, noo, not another enum/switch lover. ;)
Me and Andrew discussed this a lot, and my oppinion was and still is
that if you want enums that you can switch on, put them in a 
libggienumswitch extension. ;)
Such enums are just syntactical sugar, and I don't see any point
in bloating the main libggi with them when all information is already
available.

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

I've looked at a whole bunch of apps to check what it would take
to port them to GGI, and none of them has optimized renderers for
specific bitlayouts. Most apps should handle all common pixelformats
at least.

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se