From: Marcus Sundberg <e94_msu@e.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Tue, 14 Jul 1998 11:29:33 +0200

Re: New ggi_graphtype

Andrew Apted wrote:
> 
> Marcus writes:
> 
> >  Hi!
> >
> >  In the true spirit of DTJC I have implemented a new ggi_graphtype
> >  scheme after looking through the libggi-issues document:
> >
> >  #define        GGI_AUTO     (0)
> 
> Sounds good.
> 
> >  typedef uint32 ggi_graphtype;
> >
> >  #define GT_DEPTH_MASK        0x000000ff
> >  #define GT_ACCESS_MASK       0x0000ff00
> >  #define GT_SUBSCHEME_MASK    0x00ff0000
> >  #define GT_SCHEME_MASK       0xff000000
> >
> >  #define GT_DEPTH_SHIFT       (0)
> >  #define GT_ACCESS_SHIFT      (8)
> >  #define GT_SUBSCHEME_SHIFT   (16)
> >  #define GT_SCHEME_SHIFT      (24)
> >
> >  /* Macros to extract info from a ggi_graphtype. */
> >  #define GT_DEPTH(x)          (((x) & GT_DEPTH_MASK) >> GT_DEPTH_SHIFT)
> >  #define GT_ACCESS(x)         (((x) & GT_ACCESS_MASK) >> GT_ACCESS_SHIFT)
> >  #define GT_SUBSCHEME(x)      ((x) & GT_SUBSCHEME_MASK)
> >  #define GT_SCHEME(x)         ((x) & GT_SCHEME_MASK)
> >
> >  /* Enumerated schemes */
> >  #define GT_TEXT              ((0x01) << GT_SCHEME_SHIFT)
> >  #define GT_RGB               ((0x02) << GT_SCHEME_SHIFT)
> >  #define GT_GREYSCALE         ((0x03) << GT_SCHEME_SHIFT)
> >  /* Scheme flags */
> >  #define GT_INDEXED           ((1<<7) << GT_SCHEME_SHIFT)
> >
> >  /* Subschemes */
> >  #define GT_SUB_LSB_NORMAL    ((0x01) << GT_SUBSCHEME_SHIFT)
> >  #define GT_SUB_MSB_NORMAL    ((0x02) << GT_SUBSCHEME_SHIFT)
> >  #define GT_SUB_LSB_REVERSE   ((0x03) << GT_SUBSCHEME_SHIFT)
> >  #define GT_SUB_MSB_REVERSE   ((0x04) << GT_SUBSCHEME_SHIFT)
> 
> I was thinking of a single flag:
> 
>     #define GT_SUB_REVERSE      ((1<<7) << GT_SUBSCHEME_SHIFT)
> 
> which for modes < 8 bit would differentiate high bit/pair/nibble vs low
> bit/par/nibble.  For modes > 8 bit it would differentiate endianness
> (normal vs reversed).  It would be OR'd in.  How about that ?
> 
> 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".

So I propose that we have

#define GT_SUB_MSB          ((1<<0) << GT_SUBSCHEME_SHIFT)
#define GT_SUB_REVERSE      ((1<<1) << GT_SUBSCHEME_SHIFT)
#define GT_SUB_USE          ((1<<7) << GT_SUBSCHEME_SHIFT)

When setting a mode GT_SUB_USE indicates whether the target
should care about the other GT_SUB flags or not.
And when getting a mode !(gt>_SUB_USE) will be equal to your
GT_SUBSCHEME(gt)==GT_SUB_UNCOMMON.
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?

> 
> >  /* Macro that constructs a graphtype */
> >  #define GT_CONSTRUCT(depth,scheme,access) \
> >  ( (depth) | \
> >    (scheme) | \
> >    ((access) << GT_ACCESS_SHIFT) )
> >
> >
> >  /* Common graphtypes */
> >  #define GT_TEXT16        GT_CONSTRUCT(16,GT_TEXT,16)
> >  #define GT_TEXT32        GT_CONSTRUCT(32,GT_TEXT,32)
> 
> If depth means color-depth (which is reasonable I think) then the text
> graphtypes should be:
> 
>    #define GT_TEXT16    GT_CONSTRUCT(4, GT_TEXT, 16)
>    #define GT_TEXT32    GT_CONSTRUCT(8, GT_TEXT, 32)

Ok, I don't know much about VGA textmodes. :)

> >  #define GT_1BIT         GT_CONSTRUCT(1, GT_GREYSCALE, 1)
> >  #define GT_4BIT         GT_CONSTRUCT(4, GT_RGB | GT_INDEXED, 4)
> >  #define GT_8BIT         GT_CONSTRUCT(8, GT_RGB | GT_INDEXED, 8)
> >  #define GT_15BIT        GT_CONSTRUCT(15, GT_RGB, 16)
> >  #define GT_16BIT        GT_CONSTRUCT(16, GT_RGB, 16)
> >  #define GT_24BIT        GT_CONSTRUCT(24, GT_RGB, 24)
> >  #define GT_32BIT        GT_CONSTRUCT(24, GT_RGB, 32)
> >  #define GT_AUTO         (0)
> >  #define GT_INVALID      (0xffffffff)
> >
> [SNIP]
> >
> >  * Having GT_INDEXED as a flag instead of a searate scheme is also the right
> >    thing to do as you can have both indexed and non-indexed RGB, greyscale,
> >    YUV or whatever modes.
> 
> When I first suggested GT_RGB, what I had in mind were modes that each
> pixel contains red, green, and blue fields (such as sp16r5g6b5).  And
> GT_INDEXED was a separate graphtype where each pixel was an index into a
> palette of red, green, and blue entries.  (GT_TEXT modes were also RGB
> colored).
> 
> So the real issue here is colorspaces -- do we support extra colorspaces
> other than RGB in the LibGGI API ?  Here's what would have to be done :
> 
>     1. Change ggi_color to be a union for each colorspace, e.g.:
> 
>        typedef struct ggi_color {
>            struct { uint16 r, uint16 g, uint16 b, uint16 a } rgb;
>            struct { uint16 y, uint16 u, uint16 v, uint16 a } yuv;
>            struct { uint16 c, uint16 m, uint16 y, uint16 k } cmyk;
>        } ggi_color;

Well, I sort of considered that we could do this change later, but
it now comes to my mind that ANSI C doesn't support unnamed unions...

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.

Sounds fair?

//Marcus