From: Marcus Sundberg <e94_msu@e.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Thu, 16 Jul 1998 17:55:47 +0200

Re: New ggi_graphtype

Andrew Apted wrote:
> 
> Marcus writes:
> 
> >  > 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).
> >
> >  Well, you might be right. In that case I'd say we have two alternatives:
> >  a) Make the graphtype a struct
> >  b) Remove the subscheme from the graphtype and put the information in
> >     the mode-struct instead.
> 
> I think we should stick to the subscheme idea.  The values of subscheme
> can be arbitrary -- so long as they differentiate different modes at the
> same scheme + depth.  This way, graphtype == pixel format ==
> ggi_plb_common_setup == get/put buffer format.  Multible problems
> solved in one fell swoop.

But I think ggi_plb_common_setup should go away too!

Now that we've agreed that the core libggi should
only support the RGB colormodel there are no "common"
or "uncommon" modes. There are only:
a) modes that can be described with red/gree/blue mask and byterev,
b) modes that are indexed,
c) and then there're modes that can't be described at all

Just having arbitrary values sucks, not just because
we'll have a lot of unneccesary switchstatements everywhere,
but because it will be a PITA to add new modes (unless ofcourse
we predefine all the hundreds of possible subschemes).
It would require a central "subscheme-authority" which obviously
wont do any good...

Besides I don't see what multiple "problems" are solved.
To me the problem is having a bunch of switch-statements
with no real meaning. DirectBuffer should also use
a red/gree/blue mask.

If you like switch-statements you can always write
a libswitch extension which only have a single int
that describes a mode completely. ;-)

> >     The new members in ggi_mode would then be:
> >     ggi_pixel red_mask,
> >     ggi_pixel green_mask,
> >     ggi_pixel blue_mask,
> >     int reverse_endian,
> 
> There's no harm having that functionaly *in addition* to the graphtype,
> maybe as an API call (e.g. ggiGetTrueColorMask(vis,*r,*g,*b)) or maybe
> in some public structure -- although I doubt ggi_mode is the best place.
> 
> >     (For the 16-bit truecolor case reverse_bitness is replaced by the
> >      masks. And for indexed modes... Well, what is "reverse bitorder"
> >      on a indexed mode anyway?
> 
> On modes < 8, "reverse bitorder" is the different between sp1a8lbl
> (low bit left) and sp1a8hbl (high bit left), for example.

But there is no "left" or "right", except the physical layout on
the ramchip, and that will change as you rotate your computer. ;-)
Byteorder only matters because you may access the bytes making up
a multibyte word, and as you can't access less than 8 bits as a unit
there is no such thing as "bitorder".
If there's something I'm missing here, could you please give a
clear example of a case where "bitorder" matters?

//Marcus