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

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



On Sun, 02 Apr 2006 12:51:26 -0400 Jason Tackaberry <tack@sault.org> babbled:

> Hi raster,
> 
> On Sun, 2006-04-02 at 16:15 +0900, Carsten Haitzler wrote:
> > are you using BGRA in freevo too? you know that invovles evas having to do a
> > byteswap for all rendering as its the opposite color-order to evas's
> > internals? (which is ARGB) ?
> 
> Evas's internals are ARGB?  Well isn't that a hell of a thing.  I

ARGB when addressing pixels a DWORD (32bits) at a time. high-byte is alpha, low
byte is blue. this is incidentally the same format that about 99% of graphics
cards use natively - and have on x86 since the dawn of time (almost). anyway -
i chose this format because its *THE* most common one.

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

well see above - it depends on your terminology. i am referring to the pixel
WHEN you address it as 1 unit (a 32bit integer word) and going from MSB to LSB.

> What is imlib2's internal format?  I thought it was BGRA too.

same - i think we are mincing formats here. note - that that bug EXAMPLE used
the other format which means evas has to byteswap.

> Indeed, when I change evas to ARGB32 the problem goes away.  But I'm
> seeing very peculiar results here.  Let's go back to cvs-2005-12-18.  I
> created a BGRA32 buffer canvas and added a rectangle at the top and
> called:
> 
>     evas_object_color_set(rect, 100, 110, 120, 130);
> 
> Then I outputted the first 4 bytes of the buffer.  With 2005-12-18 I get
> this result:
> 
>    120 110 100 130
> 
> Ok, looks good.  That's BGRA.  Now here's the result when I create an
> ARGB32 canvas:
> 
>    120 110 100 130
> 
> Strange!  Same results.  BGRA.  This is probably why I was sure that
> evas's internal pixel format was BGRA :)  So with cvs-2005-12-19 ARGB32
> appears to be the same as BGRA32.

yeah - i actually never finished the support for the "byteswapped" version -
that was the real problem. the code just wasn't finished.
 
> Now, let's use yesterday's cvs.  ARGB32 canvas:
> 
>    120 110 100 130
> 
> Ok, that still looks like BGRA32 :)  But note that if I specify a BGRA32
> canvas, this is what I see:
> 
>    61 56 51 66
> 
> Obviously something is quite wrong there. 
> 
> Aside from this bug, I'm rather confused why specifying ARGB32 has a
> byte order of BGRA, which on Intel I've always called BGRA32.  Do I need
> some schooling here?

well the reason *I* call it ARGB32 is because as long as you address the pixels
by a 32bit word at a time - the ordering is identical irrespective of your
endianess. so i'm kind of removing 1 variable from the definition to make it
constant. for "packed" RGB (3 bytes per pixel, not 4) it's actually not really
possible to do this sanely - so you have no choice but to refer to it as
byte-byte-byte ordering.

> Cheers,
> Jason.
> 


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