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


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:

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]