[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] Buffer canvas and transparent background



On Sun, 2 Apr 2006 23:30:31 GMT "jose_ogp@juno.com" <jose_ogp@juno.com> babbled:

> 
>    Jason Tackaberry writes:
> 
> > Evas's internals are ARGB?  Well isn't that a hell of a thing.
> >  I thought for sure when I was looking at the raw data from
> > evas_object_image_data_get() that it was in BGRA pixel format.
> >  (Note that I'm on intel, which is little endian, so BGRA32 has
> > BGRA pixel order [low to high memory address])
> 
> 	I'm glad you've brought this issue up, since it's
> something that has always caused some confusion for me.
> 
> 	Let me thus take a minute here to write what I see as
> the relevant aspects here, and when Carsten wakes up he can set
> this straight :)
> 
> 	That evas internally uses 'argb32 pixel format' for image
> data means the following:
>  
> If you give four unsigned char values, a, r, g, b, which are
> supposed to represent the alpha, red, green, blue, components
> of a color, then evas will encode this as an unsigned int c,
> of value c = (a<<24)+(r<<16)+(g<<8)+(b).
> 	To obtain the a,r,g,b components back from c, we have
> that a = (c>>24)&0xff, r = (c>>16)&0xff, g = (c>>8)&0xff, and
> b = (c>>0)&0xff, 
> 
> 	This is, as I understand it, independent of machine byte
> order.
> 
> 	Now, if you give instead an unsigned char* s which
> is 4 bytes in size, then there are two separate but related
> notions dealing with how to obtain the pixel c (in argb32 format
> as defined above) -- one notion is the machine byte order, and
> the other is the 'pixel format' of the given s.
> 	Similarly, if we start with c, and we are asked to
> assign a 4 byte sized unsigned char* s from it, then again one
> has these two notions to deal with.
> 
> 	Let's take the case of how to assign an unsigned char *s
> (of 4 bytes in size) from the unsigned int c.
> 	We can get the a,r,g,b values as above, but there is
> a question as to how to assign these to s, ie. what values to
> give to s[0],s[1],s[2],s[3]. Should s[0] be a or b or what...
> 
> 	That is presumably what the 'pixel-format' of the output
> is supposed to determine. As I interpret this, that s has 'argb'
> pixel-format means s[0] is the a, s[1] the r, etc.. and that it
> has 'bgra' format means that s[0] is the b, s[1] the g, etc.
> 
> 	The notion of machine byte order further complicates
> matters if one tries to obtain the a,r,g,b components from c
> by casting &c to an unsigned char*, as then we have that eg.
> (unsigned char*)(&c)[0] can be either b or a, depending on wether
> the machine byte-order is big-endian or little-endian, respectively.
> 	If we are on a "big-endian" machine, like an x86, then
> (unsigned char*)(&c)[3] gives the a, whereas on a "little-endian"
> machine, a is instead (unsigned char*)(&c)[0].
> 
> 	So, eg. if on a big-endian machine:
> If s is to be in 'argb32' pixel-format, then,
>  s[0] = a = (c>>24)&0xff = (unsigned char*)(&c)[3],
>  s[1] = r = (c>>16)&0xff = (unsigned char*)(&c)[2],
> etc.
> 
> If s is to be in 'bgra32' format, then,
>  s[0] = b = (c>>0)&0xff = (unsigned char*)(&c)[0]
>  s[1] = g = (c>>8)&0xff = (unsigned char*)(&c)[1]
> etc.
> 
> 	On a little-endian machine, this becomes:
> If s is to be in 'argb32' pixel-format, then,
>  s[0] = a = (c>>24)&0xff = (unsigned char*)(&c)[0],
>  s[1] = r = (c>>16)&0xff = (unsigned char*)(&c)[1],
> etc.
> 
> If s is to be in 'bgra32' format, then,
>  s[0] = b = (c>>0)&0xff = (unsigned char*)(&c)[3]
>  s[1] = g = (c>>8)&0xff = (unsigned char*)(&c)[2]
> etc.
> 
> 	I've not really had a chance to look at what
> evas actually does for the conversions to/fro of the
> internal unsigned int 'argb32' encoded color data that
> it uses, and the various output formats.. It's possible
> that there may be some funkiness somewhere :)

there was - i never finished off the BGRA code for the buffer canvas :) i never
used it - and i think this was the first case of someone using it :)

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com
裸好多
Tokyo, Japan (東京 日本)