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

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

   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

	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],

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]

	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],

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]

	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 :)