Brian Paul wrote: > 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. >
The only case I don't understand (from a naming perspective) is BGR888, shouldn't that follow the convention and be RGB888_REV ? 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
