[cairo] Cairo + GdkPixbuf

[Krzysztof Kosiński]

2010/6/27 Bill Spitzak <spitzak at gmail.com>:
> Along with these 4-byte layouts there appears to be 3 interpretations of the
> alpha: ignore it, unpremultiplied, and premultiplied. If we only had to
> worry about sources these could just be new compositing operators. For
> destinations this does complicate things.
>
> If people really want destination images in arbitrary formats I think it
> will have to be done by making an operator on image surfaces that is "give
> me a copy of this image surface in this format". This one could not be
> written to but could be used as a source. This would avoid the N^2 problem.

There is a simpler solution
1. Read this pixel / scanline and convert it to ARGB32;
2. Compose in ARGB32;
3. Convert this new pixel / scanline to the destination surface format
and write it.
It appears that this is how it's done at the moment in Pixman
(pixman-access.c). The performance of anything other than ARGB32
probably sucks, but that's not a problem for the use cases where the
extra pixel formats would be useful.

The operation of converting the image surface in-place to a different
pixel format (but still with the same number of bits per pixel) would
be useful regardless of how compositing in weird formats is
implemented. For example when rendering SVGs to PNG images you want to
be fast, so you use remultiplied ARGB32 as the intermediate format,
but need non-premultiplied RGBA to feed to libpng.

Regards, Krzysztof