Re: CairoIO - Cairo compatible successor to GdkPixbuf
On 16/11/2007, BJörn Lindqvist <[EMAIL PROTECTED]> wrote: > > On Nov 15, 2007 10:34 PM, Mikkel Kamstrup Erlandsen > <[EMAIL PROTECTED]> 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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: CairoIO - Cairo compatible successor to GdkPixbuf
On Fri, 16 Nov 2007 14:04:45 +0100, "=?ISO-8859-1?Q?BJ=F6rn_Lindqvist?=" wrote: > 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(): Actually, better cairo code would be: if surface.get_content() == cairo.CONTENT_COLOR_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. The code I presented will be robust against future additions of color-and-alpha-supporting image formats. Another thought that occurs to me is that you should think about how to support fast loading of image data directly into cairo surfaces other than cairo-image surfaces, (for example a cairo-xlib surface). There's been recent discussion on the cairo mailing list about adding API to support this well, (for example, allowing XShm transport), and it might be very nice if you could provide some feedback on that. Let me know if you need a specific pointer to the thread(s). -Carl pgpQFpUbuM9TU.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: CairoIO - Cairo compatible successor to GdkPixbuf
On Nov 15, 2007 10:34 PM, Mikkel Kamstrup Erlandsen <[EMAIL PROTECTED]> 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? > 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. > 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. > 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. That's a really cool idea and I'll definitely look into it as soon as GIO becomes a little more stable. -- mvh Björn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: CairoIO - Cairo compatible successor to GdkPixbuf
On Nov 13, 2007 4:15 PM, BJörn Lindqvist <[EMAIL PROTECTED]> wrote: > 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? The API documentation can now be found here (looking for a better home for it): * http://trac.bjourne.webfactional.com/chrome/common/cairoio-docs/ * http://trac.bjourne.webfactional.com/chrome/common/cairoio-docs/CairoIO.pdf -- mvh Björn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: CairoIO - Cairo compatible successor to GdkPixbuf
On Thu, 2007-11-15 at 22:34 +0100, Mikkel Kamstrup Erlandsen wrote: > > 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. Yeah, this seems like a good idea. In the star trek future, the idea is that all sorts of libs that read data (from network or whatever) will produce a GInputStream. If cairoIO can read these (async and sync) it will automatically be able to consume pixbuf data from any source. Although there should still be (helper) functions to load from a GFile*, and maybe from char *path. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: CairoIO - Cairo compatible successor to GdkPixbuf
On 13/11/2007, BJörn Lindqvist <[EMAIL PROTECTED]> 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_alfaand 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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
CairoIO - Cairo compatible successor to GdkPixbuf
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! -- mvh Björn Lindqvist ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list