Re: State of gdk-pixbuf

[Bastien Nocera <hadess hadess net>]

On Thu, 2014-10-23 at 17:29 +0200, Bastien Nocera wrote:
> On Thu, 2014-10-23 at 13:02 +0100, Emmanuele Bassi wrote:
> > hi;
> >
> > On 23 October 2014 11:55, Matthias Clasen <matthias clasen gmail com> wrote:
> >
> >
> > > > I'm particularly interested to know what cairo, pixman and other image
> > > > manipulation libraries can do for us. Benjamin surely has comments[2] :)
> > >
> > > When I last talked to Soeren about it (several years ago), pixman
> > > didn't support the pixel format that gdk-pixbuf is using.
> >
> > pixman supports RGBA (r8g8b8a8 and r8g8b8x8) since 2011, because it's
> > used on big-endian architectures as well as being a requirement for
> > OpenGL ES 2.0.
> >
> > this means that it should be possible to feed a GdkPixbuf pixel buffer
> > to a pixman_image_t internally back and forth without copies, or, even
> > better, to replace the GdkPixbuf internal storage and pixops with
> > pixman_image_t and pixman operators.
>
> Indeed, that's one of the options we can take that wouldn't break ABI
> compatibility.
>
> >  it should also be possible to
> > create a tiled buffer composed by pixman_image_t tiles for large image
> > data.
>
> I have no idea what the API would look like for that.
>
> There's still the problem of handling huge files, especially the ones in
> grayscale or b&w. The uncompressed in-memory usage would balloon
> compared to what it could use if we kept it in grayscale/b&w [1].
>
> Which gets us to the problem discussed in:
> https://bugzilla.gnome.org/show_bug.cgi?id=491507
>
> We could start hiding the backing store and use cairo or pixman
> internally.
>
> gdk_pixbuf_get_pixels() would need to convert from whatever is the
> native format, to the GdkPixbuf format. Which would break applications
> expecting it to change the backing storage (say, adding borders to
> pixbufs). I'd probably do that with a slight ABI break, adding API to
> change the internal representation to the GdkPixbuf native format.

Actually, gdk-pixbuf already does that internally after Colin's commit
in https://bugzilla.gnome.org/show_bug.cgi?id=732297

So we could potentially store a pixman_image_t internally.