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

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



On Sun, 2006-04-02 at 13:40 -0400, Jason Tackaberry wrote:
> Pixel values still wrong, but at least now it's zeroing the alpha at the
> old location after object move.
> 
> So there seems to be two separate problems with BGRA32 here.

Just to follow up, I saw raster had committed a few related changes so I
reran the test against today's cvs.  (This is BGRA32):

        [tack@viper ~]$ ./a.out
        bleh
        Before move: 0,100,110,120
        bleh
        bleh
        Update: 0,0 560x40
        Update: 0,240 560x40
        After move: 0,0,0,0
        
The original issue looks fixed.  The alpha gets zeroed out in the old
location.  Thanks, raster.  (The bleh's were added by raster :))

The pixel values are now less wonky than before, but the alpha pixel
which should be 130 is 0.  Note that I called:

    evas_object_color_set(rect, 100, 110, 120, 130);

For my situation though, I need to use ARGB32, so it looks like that
although there are some issues with BGRA32, it's suddenly moot because I
should have been using ARGB32 all along.  This is all very confusing for
me, because it seems to be that what evas calls ARGB32, mplayer calls
BGRA32.  (See DOCS/tech/colorspace.txt in mplayer)  It's an endian
matter, and mplayer has standardized on opengl's definition (BE),
whereas evas seems to use LE (where ARGB32 is BGRA [low to high memory
address]).

As I'm used to mplayer's internals, and as poking through the raw data
of an evas image object showed the pixels in BGRA [again, low to high on
intel], I've been calling it BGRA32, due to my familiarity with mplayer.

Another possibility is that I'm just on seriously bad crack.

Jason.