Re: pixbuf<->cairo_surface_t conversion

[Havoc Pennington <hp pobox com>]

On Thu, Sep 2, 2010 at 1:20 PM, Matthias Clasen
<matthias clasen gmail com> wrote:
> Thanks for diving into this.
>
> As a datapoint, here is the current GTK/GDK api that directly involves
> GdkPixbuf:
>

Cool, thanks. In a quick grep, basically nothing has been changed to
pass around cairo_surface_t as a representation of "an image"

So the current situation really is that images are pixbufs it seems like.

I don't know. I know it isn't The Plan, but I'd sort of lean toward
*not* trying to change all pixbufs to cairo surface. I sort of like
the idea that cairo objects are used just during the paint(), when
they are created and immediately tossed. But for persistent objects, a
GObject is nicer. Not to mention avoiding all the deprecations and
portings and stuff.

Each pixbuf could keep a cairo_surface_t which just pointed to the
pixbuf pixels and that cairo_surface_t would be used in paint() or for
other compositing/scaling/etc. kind of operations.

In this plan, Loader and Animation would not be deprecated. However,
arguably "classic pixbuf format" and the stuff in gdk-pixbuf that only
works on it (scaling, compositing, saturate_and_pixelate, etc.) would
all be deprecated; to do that kind of stuff, you'd use cairo. Maybe
gdk-pixbuf would grow some nice convenience functions that used cairo
internally, i.e. a scale_simple() is still nice to have, and it would
use cairo to work on the cairo formats. (hmm. that's one approach -
add gdk_pixbuf_get_cairo_surface(); then make all the pixbuf
scaling/compositing APIs basically do "if cairo format, use cairo,
else use old pixbuf code" - so the pixbuf APIs become convenience
wrappers around cairo operations)

Havoc