On Tue, Feb 12, 2008 at 05:02:06PM +0000, Michel Dänzer wrote: > > On Tue, 2008-02-12 at 18:50 +0200, Ville Syrjälä wrote: > > One thing that might serve as a rule is that you should be able to copy > > RGB32 to RGB24 by simply walking both streams byte at a time and > > copying the relevant bytes (and skipping the extra bytes in RGB32). And > > since out RGB32 is native endian that implies that RGB24/BGR24 are > > stored in native endian format as well. > > Actually, as the greatest common denominator between 3 and the CPU word > size is 1, the endianness concept doesn't really make sense with RGB24 > but it can just be treated as a byte stream of colour components in a > defined order, similar to how the characters of a C string always have > the same order regardless of endianness.
Well I don't consider endianness to have anything to do with word size as such. The only thing that matters is the order we store the bytes. If we simply define that that an RGB24 pixel is RGB [23:0] we can just decide that we store that in any endianness. Your suggestion of using a the same byte order regardless of the host endianness would provide real benefits AFAICS. We could eliminate the WORDS_BIGENDIAN ifdefs in most places, and we could even share more sw rendering code between RGB24 and BGR24. To minimize breakage I think we should just choose the order that is currently used on little-endian systems ie. B first, R last for RGB24, reverse for BGR24. Big-endian systems that are currently using RGB24 would have to switch to BGR24. Or we could choose the reverse arrangement if people consider big-endian systems more important. I don't really care about 24bpp even though I'm going on about it here :) -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev