[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
Before move: 0,100,110,120
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
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.