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
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list