[cairo] Cairo + GdkPixbuf

[Krzysztof Kosiński]

2010/6/27 Bill Spitzak <spitzak at gmail.com>:
> On 06/26/2010 03:22 AM, Benjamin Otte wrote:
>> 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.

The point of supporting all those formats is reducing the memory
footprint when using data sources that are beyond the application
writer's control. There are many legitimate use cases where
compositing 3x slower but without allocating a copy of the source
surface is desirable. Right now compositing a GdkPixbuf into a Cairo
image surface requires creating a copy of the entire pixbuf. This can
double the memory footprint of the application.

Instead of forcing people to make their code fast, say it right there
in the docs for cairo_image_surface_create that the fastest format is
premultiplied ARGB32, and everything else is horribly slow. Those who
care about performance will then convert their images to the fastest
format, and those who want a small memory footprint but aren't so
concerned about performance will be able to use any data source.

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

For me it appears that compositing operations in Pixman are
implemented in a manner that is independent of the pixel format,
because everything is converted to premultiplied ARGB32 upon access.
This is OK, because as I said before the purpose of supporting many
formats is not performance.

If Pixman is in fact more complex than I imagine, then the following
two operations would satisfy most use cases I have in mind:
1. Ability to composite an image in any pixel format into an ARGB32 surface.
2. Ability to convert ARGB32 to any other format in-place. This
conversion call could have the semantics of cairo_surface_finish.

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

You can encounter data in ABGR or BGRA, or in the "wrong" endian
order, and the memory penalty would still be in effect. You don't
always have the luxury of controlling the pixel formats of all data
you have to work with.

Regards, Krzysztof