Re: CairoIO - Cairo compatible successor to GdkPixbuf

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

Some background info about this project is found here:

* gnome org/msg06472.html

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/ file. In particular I was not happy with how
PixbufAnimations work so I've tried to make them better.

Checkout using:

    svn co cairoio

The implementation is in /ref/ 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.


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