Re: GdkPixbuf vs. Cairo, new image library needed?

[Havoc Pennington <hp redhat com>]

Hi,

BJörn Lindqvist wrote:
> 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?

I would say "completely new" is scary, because the actual loaders in 
gdk-pixbuf represent years of bugfixes and contributions, and are 
security-sensitive to boot. Something completely new that didn't use 
that code would be a major regression. It might be nicer to frame the 
issue as creating a parallel cairo-centric API using the same loader code.

There is a bug for part of this, specifically I had a comment with some 
ideas:
http://bugzilla.gnome.org/show_bug.cgi?id=395578#c6

The very quick and no-brainer feature is to have a "cairo image surface 
from file / from stream" API, since apps have to cut-and-paste some ugly 
image format conversion gunk right now.

A future optimization of this API could avoid the intermediate GdkPixbuf 
object entirely, but no reason to block on redoing all the loaders to 
support that. It could be done incrementally by adding an optional 
function to the loader vtable that loaded a cairo surface, and for any 
loader missing the new function, gdk-pixbuf would emulate by doing the 
conversion from a pixbuf.

Another quick and easy step is to make things like GtkImage, TextView, 
TreeView, etc. support cairo surfaces in addition to GdkPixbuf.

Those two things (cairo surface from file/stream, and supporting cairo 
surfaces where widgets currently support pixbufs) would address most 
practical problems. Definitely would be good to get those simple fixes 
in ASAP, imo.

Havoc