Re: CairoIO - Cairo compatible successor to GdkPixbuf

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

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

On Nov 15, 2007 10:34 PM, Mikkel Kamstrup Erlandsen
<mikkel kamstrup gmail com> wrote:
> > 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!
>
>  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.

That may be a good idea.

>  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?

It is documented now. :) CairoIO merely (de)serializes images and
doesn't concern itself with the pixel data. So:

    surface = cairoio.load('foobar.png')
    if surface.get_format() in (cairo.FORMAT_ARGB32,):

is equivalent with:

    pixbuf = gdk.pixbuf_new_from_file('foobar.png')
    if pixbuf.get_has_alpha():

Cairo currently only supports one alpha format which is FORMAT_ARGB32
(FORMAT_A8 and FORMAT_A1 doesn't count), but might support more in
the future.

 

>  3) Why is there a load_xpm()?

This function is for loading inline xpm data and works exactly the
same as gdk_pixbuf_new_from_xpm_data(). The name is now
load_xpm_data() to make that clear.

> 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?

Not sure I understand? Do you mean the arguments with default values?

Yes. In fx. load_frames what will the C api look like? One method with all the args or several methods with combinations?

>   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.

What do you mean? cairoio.load () only returns a single
cairo.ImageSurface. cairoio.load_frames() is supposed to be the
full-featured general purpose method that works in all situations,
such as when you want to load thumbnails in Nautilus for example.

Ok, I don't know how I ended up writing that paragraph :-) What I meant was that load_frames() is the only method capable of scaling on the fly. So if I want to do that I have to accept that the returned value is a list packing the single frame I want. I assume the overwhelming majority of cases only use single-frame images, so why not provide a convenience variant of load() that returns only one SurfaceInfo?

>   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.

The reason is that cairoio.load() is the convenience function which
covers 95% of the use cases. So that function should be as simple as
possible because you are almost never interested in the image files
options.

It just seems inconsistent:

 load() -> Surface
 load_frames() -> [SurfaceInfo]
 load_xpm_data() -> SurfaceInfo
 load_inline() -> SurfaceInfo

Cheers,
Mikkel