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