I am confused by what you mean about the ARGB order depending on
endianess. ARGB defines the order, and each color is one byte, so
where is the ambiguity? Do you mean that depending on endianness,
cairo will use other orderings than ARGB?
In _image.cpp we provide a few buffer methods for various pixel
orderings, eg buffer_argb32. We may need to provide additional
orderings for cairo, and call the right one depending on the platform.
JDH
···
On Mon, 2007-01-08 at 11:24 -0500, Darren Dale wrote:
>> I only had a short time to work with backend_gtkcairo, but a
>> couple of things caught my attention. mathtext support seemed
>> to need some improvement, it looked like it was rendered as an
>> image rather than as text. Also, imshow(rand(100,100)) looked
>> very different with gtkcairo and gtkagg, (maybe because the
>> rgba ordering is different in agg and cairo? I'm not sure this
>> is even the case, I'm taking a stab in the dark.)
> cairo mathtext uses a method copied from gdk/gtk and does
> render an image. It needs updating to render text.
> imshow does look different on cairo and agg, and yes, It
> looks like an image format problem. cairo uses ARGB32 with
> pre-multiplied alpha, and the ARGB order depends on whether
> the machine is little- of big-endian.
This is the official definition from the manual:
CAIRO_FORMAT_ARGB32
each pixel is a 32-bit quantity, with alpha in the upper 8 bits, then
red, then green, then blue. The 32-bit quantities are stored
native-endian. Pre-multiplied alpha is used. (That is, 50% transparent
red is 0x80800000, not 0x80ff0000.)
What I think this means is:
cairo ARGB32 is stored not as 4 8-bit quantities, but as one 32-bit int.
On big-endian systems the byte order is ARGB, as you would expect, but
on little-endian systems (like a PC) the byte order is BGRA.
I imagine the reason is that its easier/faster to read/write one 32-bit
int than it is to read/write four bytes.
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com
···
On Thu, 2007-01-11 at 08:50 -0600, John Hunter wrote:
> On Mon, 2007-01-08 at 11:24 -0500, Darren Dale wrote:
>> I only had a short time to work with backend_gtkcairo, but a
>> couple of things caught my attention. mathtext support seemed
>> to need some improvement, it looked like it was rendered as an
>> image rather than as text. Also, imshow(rand(100,100)) looked
>> very different with gtkcairo and gtkagg, (maybe because the
>> rgba ordering is different in agg and cairo? I'm not sure this
>> is even the case, I'm taking a stab in the dark.)
> cairo mathtext uses a method copied from gdk/gtk and does
> render an image. It needs updating to render text.
> imshow does look different on cairo and agg, and yes, It
> looks like an image format problem. cairo uses ARGB32 with
> pre-multiplied alpha, and the ARGB order depends on whether
> the machine is little- of big-endian.
I am confused by what you mean about the ARGB order depending on
endianess. ARGB defines the order, and each color is one byte, so
where is the ambiguity? Do you mean that depending on endianness,
cairo will use other orderings than ARGB?
In _image.cpp we provide a few buffer methods for various pixel
orderings, eg buffer_argb32. We may need to provide additional
orderings for cairo, and call the right one depending on the platform.