On Sat, 15 Dec 2001, Billy Biggs wrote:
> Mark Vojkovich ([EMAIL PROTECTED]):
>
> > > The "fourcc.h" file does not contain any RGB formats. Is there any
> > > particular reason for this??http://www.webartz.com/fourcc has
> > > standard RGB formats defined as well. Why not include them for the
> > > next release.
> >
> > I don't think any drivers are using RGB formats. Also, there aren't
> > unambiguous fourcc codes for RGB as far as I can tell.
>
> Need to start somewhere to encourage driver writers to support RGB
> overlay surfaces. Why don't we start by standardizing what X uses for
> RGB fourccs.
>
> Unfortunately in the Windows world, you construct a 565 overlay by
> using the RGB bitfield fourcc and setting some other parameter to ask
> for 565, from what I remember.
Yes, which means that a single fourcc describes many different
formats. If we had to standardize on something it would probably
be 8 bit per component formats. Also, Microsoft registers all of theirs
with backwards names from the rest of the industry. It's standard to
name them from LSB to MSB (all the YUV formats are that way) but
Microsoft does it the other way around. If I were to hack something
up I would do "BGRA" which is an 8:8:8:8 ARGB format "BGRX" which is
the same but without alpha. And probably "BGR " for a 24 bpp packed
format. Most people can do these with their texture engines. I
wouldn't bother filling in the GUID field, because these are a
hack and the guid isn't valid.
I expect that this could be done faster than with drawpixels in
OpenGL for the most part, because the pipeline is much simpler
than draw pixels.
I'm reluctant to put those in fourcc.h because they're not
official. All the "official" ones registered by Microsoft
are confused and ambiguous. If anyone knows of some non-fucked-up
RGB formats registered someplace, I'd like to know about them.
We'll use those instead.
Mark.
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
