nanogui: Re: [FIX] add alpha channel into GdDrawImage software handling
Subject:
Re: Re: [nanogui] Re: Re: [FIX] add alpha channel into GdDrawImage software handling
From:
"Greg Haerr" ####@####.####
Date:
18 Mar 2010 18:51:59 -0000
Message-Id: <0df701cac6cc$06d59890$0300a8c0@RDP>
I am continuing my study of bit-endianness, and have
studied your patch as well as the interesting LJ article.
However, in the section "Endianess of IP", a
recommendation is given to
reverse the bitfield declarations of two 4-bit
fields, based on the value of an include file
constant in asm/byteorder.h: __BIG_ENDIAN_BITFIELDS.
Your code assumes the same order for declaration
of the unsigned char r:5, g:6, b:5 structure.
Shouldn't we have to look at the __BIG or
__LITTLE_ENDIAN_BITFIELDS define in
asm/byteorder.h? What is the setting for the
armeb system you tested?
Regards,
Greg
: Endian confuse me. I am studing again.
: > You are saying that
: > struct {
: > unsigned char r:5;
: > };
: > allocates the TOP (MSB) bits in big endian?
:
: Yes, in case 11110000(b)=0xF0 , r is 0x1e.
: please refer to http://www.linuxjournal.com/node/6788/print.
:
: > I don't think so.
: > I agree it allocates the top BYTE in big endian, but the
: > bits in the byte are still allocated from 0 up, not 7 down.
: > This will still allocate the LOWER 5 bits in either endian,I think.
: > So the issue is that bytes are re-ordered, but NOT bits, in little vs
big endian.
:
: typedef union
: {
: struct { unsigned char r:5 } r;
: unsigned char v;
: } BF
:
: BF c;
: c.v = 0xF0; // 11110000
:
: then,
: in a big endian c.f.r = 0x1e
: in a little endian c.f.r = 0x10
: It is tested on QEMU with arm big-endian.
: ( $ qemu-armeb a.out )
: Regards,
: Sung Joo
:
