Re: State of gdk-pixbuf

[Bastien Nocera <hadess hadess net>]

On Fri, 2014-10-24 at 09:07 -0700, Jim Nelson wrote:
> To chime in with my two cents here:
>
>
> When we started Shotwell in 2009, we got tremendous mileage out of
> GdkPixbuf.  We looked into GAGL/BABL at one point and got worried
> about speed.  (Remember, Shotwell has a non-destructive photo editor,
> meaning all transformations are applied at runtime, i.e. whenever the
> photo is accessed.)  Shotwell's transformation pipeline still uses
> GdkPixbuf; I wouldn't be opposed to moving it to pure Cairo, but why
> fix what's not broken?

By "nuking the rest" I meant remove from the gdk-pixbuf releases. You
could still copy/paste the utility functions that do blending,
compositing, copying, etc. Or move them to a library that doesn't have
the same API guarantees that gdk-pixbuf needs to have. That's still some
ways off.

> GdkPixbuf's photo loaders saved us a lot of work (although we got bit
> by the large-image bugs discussed previously).  Also, LibRaw produces
> bitmap data that's in the exact format as GdkPixbuf, and so we could
> plug in those buffers without touching the bytes.

I would expect that using using babl storage internally would diminish
the memory usage. That's probably something that I'll look at next week.

> > We could certainly nuke the rest if we think that other libraries
> > would be better equipped for resizing, clipping, scaling, and
> > compositing.
>
>
> Compositing I wouldn't miss, but the other operations ... if you need
> to load an image, do a quick operation on it, and get it into a widget
> or on the screen, GdkPixbuf is the way to go.

Right. Those are mostly utility functions. You could, right now, use
pixman instead of gdk-pixbuf to resize for example. That would be much
faster than gdk-pixbuf. If somebody is interested in porting the pixops
to pixman, we'd all owe that person a debt of gratitude ;)

> For lack of a better analogy, it would be like C++ dropping strlen,
> strncpy, etc. in place of their string object.  Sometimes when you
> have a pointer to ASCII char and need to quickly process it in a basic
> or fundamental way, the old warhorses are the way to go.

I don't see the operations disappearing, just moving somewhere else,
longer term. I'll make sure to mail this list when/if we get to that
point though.

Cheers