From: Andrew Apted <ajapted@netspace.net.au>
  To  : ggi-develop@eskimo.com
  Date: Thu, 16 Jul 1998 12:59:50 +1000

Re: New ggi_graphtype

Marcus writes:

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

:-)

Graphtypes are single values, so unless there is some other way (and
until now there hasn't been (except DirectBuffer)), that's how it has 
to be done.

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

There is hardware like this, for example RGB 6:6:4 and (IIRC) RGB 5:7:4,
so these need to be specifiable in the graphtype, especially since the
graphtype is now the pixel-format as well.  Yes, applications will
usually specify GT_AUTO for the subscheme, but they might *get back* an
RGB 6:6:4 format, so the graphtype must differentiate it from any other
16 bit format (like RGB 5:6:5).

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

Go for it.

Cheers, & Chill :-)
_____________________________________________  ____
                                               \  /
  Andrew Apted   <andrew@ggi-project.org>       \/