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

Reply via email to