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]