GdkPixbuf vs. Cairo, new image library needed?
- From: "BJörn Lindqvist" <bjourne gmail com>
- To: gtk-devel-list gnome org
- Subject: GdkPixbuf vs. Cairo, new image library needed?
- Date: Mon, 8 Oct 2007 17:45:18 +0200
Hello all, I'd like to ask some questions and maybe also start some
discussion about GDK and Cairo.
GTK+ is built on top of GDK and those libraries were built together so
they fit well with each other. But now, parts (or all?) of GDK is
about to be replaced with the much more powerful Cairo library. That
is good and it is bad, and I'll only concentrate on the bad things
because they can be fixed.
It feels like Cairo doesn't fit in. For example, GDK uses GdkColor to
represent colors but Cairo has no equivalent. Same thing with
GdkRectangle, GdkPoint and a whole host of other types that becomes
much less useful in a cairo-world.
But most problematic is probably GdkPixbuf. While gdk-pixbuf is not a
perfect library, it is the de facto standard way to represent
in-memory images in the GTK. Unfortunately, Cairo doesn't support
pixbufs at all. Or rather, it is that Cairo doesn't support any of the
two formats that GdkPixbuf supports; packed RGB24 and
RGBA32. GdkPixbufs also use non-premultiplied alpha while Cairo uses
Incidentally, blitting pixbufs is slower than it has to be because its
format rarely matches the X11 server which uses either xRGB32 or
It also doesn't seem like it is practically possible to extend
GdkPixbuf to support more formats. The API is flexible enough to allow
that, but so much code relies on pixbufs being either RGB32 or RGBA32
that it would break stuff everywhere.
So how about replacing gdk-pixbuf with something cairo compatible that
is also modern? 16 bits per sample is common these days. Support for
digital camera RAW images would also be nice. Is a completely new
image library worth pursuing? Are there maybe better ways to solve the
problems Cairo and GdkPixbuf have?
] [Thread Prev