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:
12 Mar 2010 16:42:28 -0000
Message-Id: <0f0701cac202$fe3e0140$6564a8c0@winXP>
Sung Joo -
It looks like you are right! I will study your patch again,
and accept it. Thanks alot for your suggestions and research.
The LJ article makes some pretty good points about
how C bitfields remain the same across endianness,
and it works because big endian re-numbers the
bit order as well, making bit 0 MSBit.
For testing, I am considering building a version of
the X11 screen driver for nano-X that will allow
drawing direct to framebuffer using XDGA. In
this way, we could test framebuffer code while running
on X11 desktop.
Currently, I'm running Linux on VMWare on an iMac.
I'm looking into how to change display modes so that
we might test RGB565/555 display modes by
emulating a different display mode.
Finally, it would be interesting, (although quite slow)
to test big-endian nano-X in the same way, using
QEMU!
Regards,
Greg
> 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
