From: Marcus Sundberg <e94_msu@e.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Wed, 15 Jul 1998 14:48:41 +0200

Re: New ggi_graphtype

Andrew Apted wrote:
> 
> Marcus writes:
> Users wouldn't be specifying this; the subscheme is either 0 (GT_AUTO)
> and filled in by LibGGI, or a pixelfmt-specific value which may/may not
> be OR'd with GT_SUB_REVERSE.
> 
> >  Also, for 15 and 16 bit modes GT_SUB_MSB and GT_SUB_REVERSE
> >  will not mean the same thing, so I think we should have both.
> >  Sounds good?
> 
> Yeah we need both.
> 
> After some thought, I'm thinking we should have :
> 
>     GT_SUB_BYTEREV  ((1<<7) << GT_SUBSCHEME_SHIFT)
>     GT_SUB_BITREV   ((1<<6) << GT_SUBSCHEME_SHIFT)
> 
> like you suggested, but that's all.  The subschemes values without these
> flags would still be arbitrary, but these flags say :
> 
>     if plain subscheme in N, then (N | GT_SUB_BYTEREV) is the reverse
>     endian version of N.
> 
>     if plain subscheme in N, then (N | GT_SUB_BITREV) is the version of
>     N with (for GT_INDEXED and depth < 8) the left-most bit/pair/nibble
>     is in the *least* significant part, and (for GT_DIRECT scheme)
>     *red* is in the least significant part (and blue in the most).
> 
> For example:
> 
>      mode          subscheme
> 
>      ..r5g6b5      1
>      ..r5g6b5rev   1 | GT_SUB_BYTEREV
>      ..b5g6r5      1 | GT_SUB_BITREV
>      ..b5g6r5rev   1 | GT_SUB_BITREV | GT_SUB_BYTEREV
> 
>      ..r6g6b4      2
>      ..r6g6b4rev   2 | GT_SUB_BYTEREV
>      ..b4g6r6      2 | GT_SUB_BITREV
>      ..b4g6r6rev   2 | GT_SUB_BITREV | GT_SUB_BYTEREV
> 
>      ..r5g7b4      3
>      ..r5g7b4rev   3 | GT_SUB_BYTEREV
>      ..b4g7r5      3 | GT_SUB_BITREV
>      ..b4g7r5rev   3 | GT_SUB_BITREV | GT_SUB_BYTEREV
> 
> It's really just a nice convention for creating subscheme values rather
> than for programs to do (gt & GT_SUB_XXX) with.  I think programs should
> be recognizing the *whole* graphtype, e.g. :
> 
>     ggiSetMode(...)
> 
>     switch (mode.graphtype) {
> 
>         case sp16a16r5g6b5:     render_rtn = &render_n_r5g6b5; break;
>         case sp16a16r5g6b5rev:  render_rtn = &render_r_r5g6b5; break;
>         case sp16a16b5g6r5:     render_rtn = &render_n_b5g6r5; break;
>         case sp16a16b5g6r5rev:  render_rtn = &render_r_b5g6r5; break;
> 
>         case sp16a16r6g6b4:     render_rtn = &render_n_r6g6b4; break;
>         case sp16a16r6g6b4rev:  render_rtn = &render_r_r6g6b4; break;
>         case sp16a16b4g6r6:     render_rtn = &render_n_b4g6r6; break;
>         case sp16a16b4g6r6rev:  render_rtn = &render_r_b4g6r6; break;
> 
>         default:
>             /* Unknown format, fall back to using a memory visual
>              * and ggiCrossBlit...
>              */
>     }

Could you PLEASE tell me what's so good with having a >30 level
switch-statement in every target to convert the useful information
into a weird subscheme, and then forcing every application to
have another >30 level switch-statement to convert the useless
subscheme into useful information?

For GT_DIRECT all you need to _COMPLETELY_ describe a pixelformat is:
red_mask
blue_mask
green_mask
GT_SUB_BYTEREV

The reason I used GT_SUB_BITREV in my subscheme suggestion instead
of the masks is that:
a) They wouldn't fit in the graphtype
b) If there should be hardware that supports diffrent masks
   for the same depth I doubt that there're any applications
   that would want to specify it anyway. It should be enough
   to _query_ the masks.
   
I want all the features of libggi to work as intended, and
I want to implement them. But I do NOT want to implement
things that will bloat libggi, bloat applications and make
libggi hard to use just because of something that 0.1% of
the applications possibly  might think is a slight bit
better!

There are basicly two kinds of applications that will use GT_DIRECT:
The ones that use ggiMapColor to construct a lookuptable of
pixelvalues that they will later use by indexing the table, and
the ones that wan't to encode pixels directly.
The first kind won't care whether we use masks or stupid defines,
but to the second the sp* stuff is worthless, while the masks
is exactly what it needs.

> So how about keeping it simple by using the following four schemes ?
> 
>     GT_TEXT
>     GT_DIRECT
>     GT_INDEXED
>     GT_GREYSCALE

I suggest GT_TRUECOLOR and GT_CLUT instead of GT_DIRECT and
GT_INDEXED. I find the former much more intuitive.

//Marcus