[EMAIL PROTECTED] wrote:
>
> Quoting Stefan Seefeld <[EMAIL PROTECTED]>:
>
> > I didn't even know the visual *contains* alpha channel data !
> > While the pixel format allows for alpha bits, all the visuals I have
> > inspected had only r, g, and b bits.
>
> I made the assumption (I know, assume makes an ass of u and me) that a
> GT_32BIT display use the last 8 bits as an alpha channel. It sounded natural
> since a ggi_color is defined as :
>
> struct {
> uint16 r, g, b, a;
> }
>
> So I thought the alpha channel would be packed in the ggi_pixel
> if the visual supports it. If not I think the 'a' is useless and
> confusing since ggi doesn't do alpha blending at all.
don't make any assumptions, use the information from the pixel format instead.
It took me a while to understand how to get to the real masks/values, but if you
look for a while at the pixel format definition (the xxx_shift and xxx_mask fields),
then do an actual test, i.e. write these numbers out for a given visual, you'll note
that there is indeed no alpha channel.
The GGI developers are certainly in a better position to explain you the reason,
but I can immagine that it was a measure of maximum flexibility. I too found it strange
to have the option for alpha channel data *in the visual* when all blit operations
don't
take care of that (i.e. do a simple dump).
Anyway, it appears that if you want to operate with alpha channels, you have to use
libart's buffers to do that and then crossblit the result into the visual. That's how
we do it in the libart DrawingKit in berlin anyway...
Regards, Stefan
_______________________________________________________
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: [EMAIL PROTECTED]
_______________________________________________________
...ich hab' noch einen Koffer in Berlin...
