Re: CairoIO - Cairo compatible successor to GdkPixbuf

["Mikkel Kamstrup Erlandsen" <mikkel kamstrup gmail com>]

On 13/11/2007, BJörn Lindqvist <bjourne gmail com> wrote:

Hello all!

Some background info about this project is found here:

* http://www.mail-archive.com/gtk-devel-list gnome org/msg06472.html
* http://live.gnome.org/GtkCairoIntegration
* http://bugzilla.gnome.org/show_bug.cgi?id=395578#c6

In short, GdkPixbuf has some big problems which are hard to solve, so
we need a new image library which is more compatible with Cairo.
CairoIO is my attempt at creating such a library. The library is not a
reimplementation of GdkPixbuf, it only wraps it to provide a
cairoified front end to all the image loading functionality.

Currently it consists of nothing more than a executable specification
written in Python and unit tests. The intention is to first create a
rock-solid, future-proof interface that solves all architectural
problems GdkPixbuf has. So lets have some nice discussion about it!
The things I've found really bad with GdkPixbuf and which I think
CairoIO can solve are listed in "Targeted GdkPixbuf Problems" in the
/ref/cairoio.py file. In particular I was not happy with how
PixbufAnimations work so I've tried to make them better.

Checkout using:

    svn co svn.gnome.org/svn/cairoio/trunk cairoio

The implementation is in /ref/cairoio.py which also contain lots of
documentation. I know the name "CairoIO" might not be so nice, but it
is only seven characters. Maybe someone can think of a better name?

Feedback welcome!

And thou shalt have feedback :-)

 1) I am wondering if it should integrate with the upcoming libgio? Ie, take a GFile instead of a filename in function args..? Or maybe going entirely G{Input,Output}Stream based? That would obsolete a few of the methods in the API.

 2) I see that you do not have any methods to match GdkPixbuf.get_has_alfa and a handful other methods on GdkPixbuf. Is the reason documented somewhere or am I missing something obvious?

 3) Why is there a load_xpm()?

4) I gather that the load*() family functions replace the constructors of GDkPixbuf.
  4.1) How exactly would you map the load_frames() method with the keyword arguments?
  4.2) Why do I have to call load_frames() to request the image size on construction of the surface? Just load() would space me the linked list for normal images.
  4.3 (Assuming gio based) If we are in stream terminology s/load/read is probably more in line

5) All load_*() family functions returns a SurfaceInfo, but load() returns a Surface... A bit odd maybe.

I am really exited about the idea about joggling cairo surfaces around over G{In,Out}putStreams, but the idea may be bonkers, I have not read the GIO api much, not do I understand the finer details of cairo surfaces.

Cheers,
Mikkel