From: Marcus Sundberg <e94_msu@e.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Fri, 17 Jul 1998 10:23:44 +0200

Re: New ggi_graphtype

Andrew Apted wrote:
> 
> Marcus writes:
> >  c) and then there're modes that can't be described at all
> 
> Yep.  In other words, you could call them "uncommon" :-)

"uncommon" modes are modes that can be described but doesn't
have a sp* value. And as there are no such modes in either
of our schemes there are no "uncommon" or "common" modes.

> >  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...
> 
> I'm not proposing that we define subschemes values as stand-alone
> entities.  What I am proposing is to define *pixel formats* by filling
> in the subscheme with different values.  Like this :
> 
>         pixel format         scheme    subscheme  access  depth
> 
>         sp1a8lbl             GT_CLUT          1      8      1
>         sp1a8hbl             GT_CLUT          2      8      1
>
>         sp2a8lpl             GT_CLUT          1      8      2
>         sp2a8hpl             GT_CLUT          2      8      2
> 
>         sp4a8lnl             GT_CLUT          1      8      4
>         sp4a8hnl             GT_CLUT          2      8      4
>
>         sp8a8i8              GT_CLUT          1      8      8
> 
>         sp8a8k8              GT_GREYSCALE     1      8      8
> 
>         sp16a16r5g5b5A1      GT_TRUECOLOR     1     16     15
>         sp16a16r5g5b5A1rev   GT_TRUECOLOR     2     16     15
>         sp16a16b5g5r5A1      GT_TRUECOLOR     3     16     15
>         sp16a16b5g5r5A1rev   GT_TRUECOLOR     4     16     15
> 
>         sp16a16r5g6b5        GT_TRUECOLOR     1     16     16
>         sp16a16r5g6b5rev     GT_TRUECOLOR     2     16     16
>         sp16a16b5g6r5        GT_TRUECOLOR     3     16     16
>         sp16a16b5g6r5rev     GT_TRUECOLOR     4     16     16
> 
>         sp24a8b8g8r8         GT_TRUECOLOR     1     24     24
>         sp24a8r8g8b8         GT_TRUECOLOR     2     24     24
> 
>         sp32a32b8g8r8A8      GT_TRUECOLOR     1     32     24
>         sp32a32b8g8r8A8rev   GT_TRUECOLOR     2     32     24
>         sp32a32r8g8b8A8      GT_TRUECOLOR     3     32     24
>         sp32a32r8g8b8A8rev   GT_TRUECOLOR     4     32     24
> 
>         sp4a16t8             GT_TEXT          1     16      4
>         sp4a16t8rev          GT_TEXT          2     16      4
>         sp8a32t8             GT_TEXT          1     32      8
>         sp8a32t8rev          GT_TEXT          2     32      8
>
> [The central authority is just the header file where we define those
>  values (like ggi/keyboard.h is the central authority for key values)].

The file won't update itself whenever J Random Hacker want's support
for a new subscheme. If he doesn't want to use that subscheme only
in his own libggi, he'll have to contact the central authority
maintaining the headerfile in order to be assigned one of the magic
numbers you want to use for subschemes.

> >  To me the problem is having a bunch of switch-statements
> >  with no real meaning.
> 
> The whole graphtype has meaning (as above), and we switch on that
> (whenever we have to).  I'm not suggesting we switch on the subscheme
> values alone.

Having random values in the subscheme makes the entire graphtype
random. And there's no "whenever we have to". The TARGETS will
have to switch - always, to construct the graphtype.
And the applications will have to switch whenever they care about
the pixelformat at all.

One of your earlier arguments for the random subsceme numbers
was that you wanted support for things like r7g5b4. Unless
you wan't to have a central authority handing out magic
numbers when they're needed like described above, we'll have
several hundreds of switchlevels in every target!

My scheme would add 6 lines of code to the X-based targets,
maybe 20 lines to the SVGAlib target, and for most other
targets even less. Your scheme, if fully supported, would add
several hundreds of lines to ALL targets!

The main point is that the sp* things are not good for anything,
they're just bloat! And as I said - if you like switch-statements,
make a libggiswitch extension. ;)

> >  DirectBuffer should also use a red/gree/blue mask.
> 
> It does, look closer.  It's the array of pixelattributedescs (pad) at
> the end of ggi_pixellinearbuffer.  Mmmmmm, that sure is a fun one to
> decode... :-)

I know, that's another of the things that makes no sense in
the current libggi. As we're only supporting RGB colorspaces
in the core libggi we won't need most of the attributes.
And the ones we'll useshould be accessible directly in
the ggi_pixellinearbuffer struct, not hidden in a most
weird way...
My proposed ggi_pixellinearbuffer would look like:

typedef struct ggi_pixellinearbuffer
{
        void    *read;                  /* buffer address for reads     */
        void    *write;                 /* buffer address for writes    */
        ggi_uint        page_size;      /* zero for true linear buffers */

        ggi_uint        access;         /* supported access widths      */
        ggi_uint        align;          /* alignment requirements       */
        ggi_uint        swap;           /* swapping requirements        */

        /*      buffer layout   */
        ggi_uint        bpp;            /* bits per pixel               */
        ggi_sint        stride;         /* bytes per row               */
        ggi_coord       origin;         /* application area origin      */
        ggi_coord       size;           /* size of application area     */

	/* Masks for pixelattributes */
        ggi_pixel       paPrivate,              /* Don't touch                          P */
        ggi_pixel       paApplication,          /* store what you want in here          A */
        ggi_pixel       paBackgroundIndex,      /* index of the color of the pixel      i */
        ggi_pixel       paForegroundIndex,      /* index of the color of the texture    F */
        ggi_pixel       paTextureIndex,         /* index of the texture                 t */
        ggi_pixel       paBlink,                /* blink bit/frequency                  B */
        ggi_pixel       paRed,                  /* intensity of color channel 1         r */
        ggi_pixel       paGreen,                /* intensity of color channel 2         g */
        ggi_pixel       paBlue,                 /* intensity of color channel 3         b */
} ggi_pixellinearbuffer;

> >  > >     The new members in ggi_mode would then be:
> >  > >     ggi_pixel red_mask,
> >  > >     ggi_pixel green_mask,
> >  > >     ggi_pixel blue_mask,
> 
> Here's a nice idea I had earlier today: when scheme == GT_TRUECOLOR and
> subscheme != GT_SUB_UNCOMMON, programs are allowed to use ggiMapColor()
> to get the masks.  Something like this:
> 
>     red_mask   = ggiMapColor(vis, {0xffff, 0x0, 0x0});
>     green_mask = ggiMapColor(vis, {0x0, 0xffff, 0x0});
>     blue_mask  = ggiMapColor(vis, {0x0, 0x0, 0xffff});
> 
> That way, no extra API is needed at all.

Well, what you're proposing is an extra API to wrap the real
information. I wan't to avoid bloat and make that information
directly available.

> >  > 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. ;-)
> 
> Think screen image.  sp1a8lbl has the left-most pixel in bit #0 of each
> byte, sp1a8hbl has the left-most pixel in bit #7 of each byte.  I could
> draw a diagram if you like :->>.

Ops, guess I was to much centered towards 8-bit modes only...
I got the picture now. ;)

//Marcus