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.
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.