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

Re: New ggi_graphtype

Marcus writes:

>  > I also had in mind a special value meaning Unknown/Uncommon/Private,
>  > for modes that programs shouldn't try to understand (such as encoding /
>  > decoding pixels or get/put buffers).  Such modes would be limited to
>  > using ggiMapColor() & ggiUnmapPixel().  For example, a YUV mode that
>  > we're pretending to be RGB.
>  > 
>  >     #define GT_SUB_UNCOMMON     ((0xff) << GT_SUBSCHEME_SHIFT)
>  
>  Ok, I actually thought about this, but I guess I needed to read
>  your comment until all my thoughts were connected. ;)
>  The problem with just a GT_SUB_REVERSE flag is that there's no
>  difference between the user saying "I don't care" and
>  "I absolutely don't want GT_SUB_REVERSE".

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...
	     */
    }

>  Ok. I suggest that we keep GT_INDEXED as a flag for maximum flexibility,
>  but we agree on that other colorspaces than RGB will not go into the
>  core libggi. If/when someone want's YUV/CMYK support they will have
>  to implement it as an extension.

Argh... :)

If LibGGI sticks to being RGB only (and I'm happy with that), then
GT_INDEXED as a flag doesn't make any sense.  Let's rename GT_RGB to
GT_DIRECT so we don't get confused with colorspaces.  With GT_INDEXED as
a flag, we get six possibilities :

    GT_TEXT         GT_INDEXED | GT_TEXT
    GT_DIRECT       GT_INDEXED | GT_DIRECT
    GT_GREYSCALE    GT_INDEXED | GT_GREYSCALE

and presumable plain indexed mode would be GT_INDEXED | 0.  There's no
advantage in that, most of it doesn't make sense, and for the arguable
bit that does (GT_TEXT), the distinction isn't worth the extra
complexity.

So how about keeping it simple by using the following four schemes ?

    GT_TEXT
    GT_DIRECT
    GT_INDEXED
    GT_GREYSCALE

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

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