Michel Dänzer wrote:
> On Thu, 2006-09-21 at 12:58 +0100, Keith Whitwell wrote:> Michel Dänzer
> wrote:> > On Wed, 2006-09-20 at 18:56 +0000, Keith Whitwell wrote:> >>> >>
> Log message:> >> Support both big and little endian, more source types and
> more> >> destination formats through the swizzle path. It would be great
> to> >> see this tested on eg, PPC machines...> > > > With the current
> trunk, glean pixelFormats fails 201 combinations on big> > endian with both
> drivers, of which this commit broke 42 and the 'Extend
> 'Both drivers' referring to r200 and r300 BTW. I haven't tried softwareMesa
> yet.
>>> swizzle support to all remaining source formats and texture destination> >
>>> formats.' commit the other 159 (yay git-bisect! :).> > > > Changing
>>> type_endian_mapping() to return map_identity for> > GL_UNSIGNED_BYTE brings
>>> it down to 144 and changing the last two> > components of map_3210 to { 7,
>>> 6 } to 138, > > I think this must be a fluke - the 4,5 there refer to
>>> ZERO,ONE defined > elsewhere. Those values are always at 4,5 and are only
>>> addressed as > elements in an array of bytes - I can't see how their
>>> positions might > change in littleEndian machines.
> Yeah, as I said, I didn't really know what I was doing, it was justtrial and
> error. :)
The whole idea is to compute a mapping from ubytes in the incoming data
to ubytes in the desired internal image format. Any 8bpp color image
can be converted into any other by an extended swizzle at each pixel, ie
a mapping of the orignal ubytes plus a hardcoded ZERO and ONE value
onto the destination.
Calculating what that mapping should be is suprisingly complex, and is
what all the fuss is about.
Take srcFormat: GL_RGBA
srcType: GL_UNSIGNED_BYTE
internalFormat: GL_RGB
destFormat: argb8888
We need to convert from RGBA->RGB->argb8888.
It might be possible to store conversion mappings between all possible
combinations of srcFormat, internalFormat and destFormat, but the table
would be huge.
Even just storing the mappings between any pair of formats is too much
data. Instead, what I've done is store mappings to/from GL_RGBA which I
can concatenate as necessary:
RGBA->RGBA, RGBA->RGB, RGB->RGBA, RGBA->argb8888
It should also be possible to handle littleEndian and
srcPacking->swapBytes by concatenating further mappings which account
for how the ordering of the source data differs from what we'd get if we
had it in "GLubyte rgba[4]" format.
So, type_endian_mapping should provide a mapping between (GLubyte
*)(TYPE *)data and what you'd get if you placed r,g,b,a into a GLubyte
data[4] value.
Swapbytes takes place after that conversion and probably doesn't need to
change for BE vs. LE, but I could be wrong...
Keith
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
