[cairo] Cairo + GdkPixbuf
spitzak at gmail.com
Sat Jun 26 16:35:06 PDT 2010
On 06/26/2010 03:22 AM, Benjamin Otte wrote:
> On Sat, 2010-06-26 at 03:33 +0200, Krzysztof Kosiński wrote:
>> The fact that Cairo cannot understand non-premultiplied RGBA which is
>> used in GdkPixbuf is somewhat inconvenient.
> Yes, RGBA is the obvious choice of people new to image formats, because
> it's how people think of pixels. Which is why it shows up in every
> project that needs graphics but has inexperienced developers (like Gtk1,
> HTML5 canvas or the PNG specification).
> That alone is a good enough reason for adding support for these formats
> to Cairo.
I don't know about this, it would seem that would continue to allow
inexperienced developers to use the slower formats. Not supporting them
may force them to make their source images in the faster format.
I started on this work, but there are still some disagreements
> on how to best support the formats' requirements (see below), so it
> might take a while until my patches (or reworked versions) land in the
> code repositories. But it's definitely my intention to get support for
> these formats into Cairo. (Note to self: Talk to Søren about how to do
> this stuff in Pixman again).
>> I have some questions:
>> 1. What is the amount of work necessary to add support for a new pixel
>> format in the image surface?
>> 2. Does supporting N pixel formats require O(N) or O(N^2) code?
It can be reduced to O(N) if more pixmap formats are allowed for source
images than destinations. This would likely cover what everybody really
wants. Also the number of compositing operations directly supported can
be limited to OVER and COPY, all others either cause an error or (more
likely) are done by COPY to a temporary surface and then compositing
As far as I can tell there are only *two* 4-byte image formats of any
interest: "ARGB32" and "RGBA".
The confusion is with endianess. If you look at the bytes in memory for
ARGB32 you will see BGRA on a little-endian machine, and ARGB on a
big-endian. This seems to cause people to think that at least a third
format is needed, but this just is not true. *only* the ARGB32 format is
used, with whatever layout it happens to be on that machine.
Non-premultiplied should be supported, but only as a source image. A
weird thing is the Cairo documentation shows all the math in
non-premultiplied form, even though it would be much simpler in
premultiplied. Cairo also needs a way to specify the color already
premultiplied, my recommendation is there be an API that in effect sets
the color to a 1x1 image, where this image can be any format that Cairo
More information about the cairo