Re: pixbuf<->cairo_surface_t conversion

[Havoc Pennington <hp pobox com>]

Hi,

2010/9/2 Krzysztof Kosiński <tweenk pl gmail com>:
> The functions are unnecessarily general. Only two functions are
> needed: an in-place conversion of an entire pixbuf, and duplication
> with conversion (to cover cases where the number of bytes per pixel is
> different, or lossy conversion). There's no need to support copying
> regions between pixbufs with conversion, because compositing is
> Cairo's job.

The region copy is needed for incremental pixbuf load in
GdkPixbufLoader, I think. If it isn't then I agree the function isn't
super useful.

The way I would see things working is that most of the image loader
backends could continue to generate pixbuf's classic format, but if
you'd asked for cairo format, the loader would create a second pixbuf
in the cairo format and then copy over the areas as they load,
exposing only the second cairo-formatted pixbuf to the application.
(Assuming the app has requested cairo format.)

I initially had a function that did a "destructive" convert of a
pixbuf, which was in-place if possible. A trick is that all props on
pixbuf are currently immutable (CONSTRUCT_ONLY). We could change that,
of course. But it's sort of a messy change for only an optimization,
and it's not like setting n_channels post-construct is allowed, so
removing CONSTRUCT_ONLY is kind of wrong. Also, for the incremental
load, you would end up with a pixbuf that was partly in one format and
partly in another format. That would be... weird. Though it might
work.

Making the PNG and JPEG loaders load without a convert, and adding
cairo's formats to the pixdata inline stuff, might be good enough to
avoid conversion in practice in almost all real applications. With
copying convert as a rare fallback which could just be slightly
inefficient instead of in-place. i.e. TIFF support can have some extra
overhead and we'll survive it.

i.e. the idea is that in-place conversion is sort of thorny and the
optimization really isn't important as long as we avoid conversion in
the three or so common cases. And avoiding conversion entirely does
save CPU, while in-place only saves memory but still uses CPU.

> The conversion between non-premultiplied BE RGBA to premultiplied
> native-endian ARGB is lossless in practice. E.g. even if you convert
> back to non-premul, it doesn't matter in most cases, because to
> display the image on the screen you'll have to convert back to premul
> anyway. So instead of modifying all the loaders, we could just convert
> to the new format after loading.

The only reason to modify the loaders would be efficiency, just to
avoid a convert. My thought was to first implement loading with a
convert fallback, but then as an optimization, loaders could support
directly loading to the proper format.

Whether we optimize with an inplace convert or with loaders knowing
about the destination format, a copying convert seems like a simple
place to start, so that's why the initial API here is copying.

Havoc