[cairo] Cairo + GdkPixbuf

[Bill Spitzak]

On 06/26/2010 03:22 AM, Benjamin Otte wrote:
> On Sat, 2010-06-26 at 03:33 +0200, Krzysztof Kosiński wrote:
>> Hello
>>
>> 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 
from there.

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