On Sun, 02 Apr 2006 12:51:26 -0400 Jason Tackaberry <[EMAIL PROTECTED]> 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) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
