Re: State of gdk-pixbuf

[Jim Nelson <jim yorba org>]

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?

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.

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.

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.

-- Jim