Michel Dänzer wrote: >Keith wrote: > >>> I think from Brian's description of the meaning of the >>> texture format struct naming, a driver that wanted a >>> different component order in a packed field would have >>> to specify a different texformat struct - ie the >>> component ordering for a given texformat struct is fixed.
>> Ah, I was confused by the different meanings of the _REV >> suffix for the OpenGL formats and Mesa's internal hardware >> formats. Looks like it just means byte swapping for the >> latter. In fact, given the naming scheme for the mesa >> texformats, I wonder why the _rev designation is necessary >> at all -- shouldn't _argb8888_rev just be called bgra8888 ? >> > > That would work for the formats where component and byte > boundariesalign, but e.g. GBARG35152 instead of ARGB1555_REV would > be a littleweird, wouldn't it? :) That's correct. The 32-bit formats don't really need to use the _REV convention, but it works well for the 16-bit formats. -Brian ------------------------------------------------------------------------- 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 Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
