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
