nanogui: Thread: problem with transparent color

Hi,

I found a problem that when I load images with the RGB color 255,255,255
it will translate it as transparent color, because the 
PMWIMAGEHDR::transcolor
is -1.

Regards,
Eric Co

On 06/04/06 19:05 +0800, Eric Co wrote:
> Hi,
> 
> I found a problem that when I load images with the RGB color 255,255,255
> it will translate it as transparent color, because the 
> PMWIMAGEHDR::transcolor
> is -1.

Are you running on a 16 bit system or something?  There are a few things
confusing me.  First, on a 32 bit system, 0x00FFFFFF can't possibly be 
negative, let alone be -1.  Secondly, the latest CVS shows the transcolor 
as 0x01000000, which also cannot possibly be -1. 

Of course, if you are on something other then a 32 bit system, all bets
might be off.

Jordan
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 
> 

-- 
Jordan Crouse
Senior Linux Engineer
AMD - Personal Connectivity Solutions Group
<www.amd.com/embeddedprocessors>

: Are you running on a 16 bit system or something?  There are a few things
: confusing me.  First, on a 32 bit system, 0x00FFFFFF can't possibly be
: negative, let alone be -1.  Secondly, the latest CVS shows the transcolor
: as 0x01000000, which also cannot possibly be -1.

No, this problem appeared after the contribution for hardware
alpha channel support.  The MWRGB macro effectively
changed to MWARGB, with the A (hi byte) normally defaulting
to full alpha = 255.  This caused WHITE to become -1,
which matched the old transparent color -1.  In the CVS
version, this has been fixed, and transcolor is now 0x01000000.

The ARGB colors are always specified as 32 bits, regardless
of the framebuffer color size.

Regards,

Greg



: > I found a problem that when I load images with the RGB color 255,255,255
: > it will translate it as transparent color, because the
: > PMWIMAGEHDR::transcolor
: > is -1.