Re: pixbuf-cairo_surface_t conversion
On Fri, 2010-09-03 at 21:49 +0100, Alberto Ruiz wrote: For what it's worth, libgpod has a gdk-pixbuf dependency and no cairo dep, and people complain from time to time about that dependency (though that's mainly on distros where gdk-pixbuf is in the same package as gtk+, which will no longer be the case with gtk3). So I don't know how they will react to an additional cairo dep ;) Well, since currently gdk-pixbuf comes inside Gtk+, and Gtk+ depends on cairo. this is not true any more, since GDK-Pixbuf has been split from GTK+ and it's a separate library once again. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf-cairo_surface_t conversion
2010/9/4 Emmanuele Bassi eba...@gmail.com: Well, since currently gdk-pixbuf comes inside Gtk+, and Gtk+ depends on cairo. this is not true any more, since GDK-Pixbuf has been split from GTK+ and it's a separate library once again. Which is the actual point of my argument :P ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf-cairo_surface_t conversion
Matthias Clasen matthias.cla...@gmail.com writes: On Thu, Sep 2, 2010 at 7:24 PM, Havoc Pennington h...@pobox.com wrote: I was thinking about the problem of wasting memory, writing to one internal representation and not changing the other, etc. How about this: we only keep one representation around. If you get_pixels we drop the surface, if you get_cairo_surface we drop the old-style pixels. We deprecate get_pixels() which is the only call that can force the old-style representation to be created. If you do use get_pixels(), what's going to happen is that you do your pixel editing, and on the next paint gdk_pixbuf_get_cairo_surface() will force conversion back to cairo representation. Here is an (untested) patch to implement this. Not that it matters that much, but if you use cairo_mask() with the pixbuf data as both source and mask, the source as RGB24 and the mask as ARGB32, you could make cairo do the conversion from pixbuf to surface. That would likely hit an SSE2 or ARM NEON optimized code path in pixman. Soren ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf-cairo_surface_t conversion
On Thu, 2010-09-02 at 19:24 -0400, Havoc Pennington wrote:
We deprecate get_pixels() which is the only call that can force the
old-style representation to be created. If you do use get_pixels(),
what's going to happen is...
Deprecate¹ implies removal at either GTK 3.0 or GTK 4.0, right?
So I guess the question I have is is there ever a legitimate usage to
get the individual pixels.
Our binding of this right now is:
http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/gdk/Pixbuf.html#getPixels()
which is mostly used by us for testing; I couldn't begin to guess what
other people have used it for; I do know one crew that actually did some
image recognition work (feeding some other library from these byte[]).
We can kiss gdk_pixbuf_get_pixels() goodbye, no problem, but I'm just
curious what someone would replace it with... draw to a Cairo image
surface, save that to a PNG and then load it and... oh wait. :)
As usually happens across the language barrier, we had to copy the array
anyway, so I'm not really fussed where we get it from. Or, are we
advised to tell developers no more access to an image's pixels?
{shrug}
AfC
Sydney
¹ deprecate of course means don't use this it's been replaced or
just plain don't use it but in GTK during the long lifespan of 2.x
we've also used it to mean we'd rather you didn't use it but it's still
ok... because (until the last ~18 months) we were in
ain't-never-ever-gonna-remove-functions mode.
Now we're actually removing stuff! Who would have thunk it :)
I think there's some inconsistency in our library as a result of this. A
number of times over the last few months Javier has had his enthusiasm
pushed back when he's seen rather you didn't use this, not known it's
still ok, and thought it should be removed only to be told to leave it
alone.
signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf-cairo_surface_t conversion
Hello there,
at college, we used get_pixels for concurrency assignments where we
used Ada. (Histogram analysis, shape detection and whatnot)
The problem I see with removing this is that you actually need to make
a roundtrip from the GDK API to cairo_get_surface - cairo_get_data
which would not be a very obvious step from the API user point of
view.
If we are trying to keep things cairo internally, can't we just leave
get_pixels as a wrapper around cairo's get_surface/get_data if that's
how people are going to have to use it anyway?
Cheers,
Alberto
2010/9/3 Andrew Cowie and...@operationaldynamics.com:
On Thu, 2010-09-02 at 19:24 -0400, Havoc Pennington wrote:
We deprecate get_pixels() which is the only call that can force the
old-style representation to be created. If you do use get_pixels(),
what's going to happen is...
Deprecate¹ implies removal at either GTK 3.0 or GTK 4.0, right?
So I guess the question I have is is there ever a legitimate usage to
get the individual pixels.
Our binding of this right now is:
http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/gdk/Pixbuf.html#getPixels()
which is mostly used by us for testing; I couldn't begin to guess what
other people have used it for; I do know one crew that actually did some
image recognition work (feeding some other library from these byte[]).
We can kiss gdk_pixbuf_get_pixels() goodbye, no problem, but I'm just
curious what someone would replace it with... draw to a Cairo image
surface, save that to a PNG and then load it and... oh wait. :)
As usually happens across the language barrier, we had to copy the array
anyway, so I'm not really fussed where we get it from. Or, are we
advised to tell developers no more access to an image's pixels?
{shrug}
AfC
Sydney
¹ deprecate of course means don't use this it's been replaced or
just plain don't use it but in GTK during the long lifespan of 2.x
we've also used it to mean we'd rather you didn't use it but it's still
ok... because (until the last ~18 months) we were in
ain't-never-ever-gonna-remove-functions mode.
Now we're actually removing stuff! Who would have thunk it :)
I think there's some inconsistency in our library as a result of this. A
number of times over the last few months Javier has had his enthusiasm
pushed back when he's seen rather you didn't use this, not known it's
still ok, and thought it should be removed only to be told to leave it
alone.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
--
Un saludo,
Alberto Ruiz
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf-cairo_surface_t conversion
2010/9/3 Andrew Cowie and...@operationaldynamics.com We can kiss gdk_pixbuf_get_pixels() goodbye, no problem, but I'm just curious what someone would replace it with... draw to a Cairo image surface, save that to a PNG and then load it and... oh wait. :) You can get the pixels from the cairo image surface with cairo_image_surface_get_data(). It wouldn't make sense to alias these two since the stored formats are not compatible so code needs to adapt to it anyway. Btw, just to state the obvious, this stuff rocks :) -- Kalle Vahlman, z...@iki.fi Powered by http://movial.com Interesting stuff at http://sandbox.movial.com See also http://syslog.movial.fi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf-cairo_surface_t conversion
2010/9/3 Alberto Ruiz ar...@gnome.org: Hello there, at college, we used get_pixels for concurrency assignments where we used Ada. (Histogram analysis, shape detection and whatnot) The problem I see with removing this is that you actually need to make a roundtrip from the GDK API to cairo_get_surface - cairo_get_data which would not be a very obvious step from the API user point of view. The description in http://library.gnome.org/devel/gdk-pixbuf/unstable/gdk-pixbuf-gdk-pixbuf.html (which seems currently a bit sparse ;) could specifically explain this use-case, so I don't think it would be too far-fetched. OTOH, you could always add gdk_pixbuf_get_data() which would amount to cairo_image_surface_get_data(gdk_pixbuf_get_surface(p))... If we are trying to keep things cairo internally, can't we just leave get_pixels as a wrapper around cairo's get_surface/get_data if that's how people are going to have to use it anyway? ...but not replace get_pixels() due to the incompatible storing formats. -- Kalle Vahlman, z...@iki.fi Powered by http://movial.com Interesting stuff at http://sandbox.movial.com See also http://syslog.movial.fi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf-cairo_surface_t conversion
Hi, On Fri, Sep 3, 2010 at 4:05 AM, Andrew Cowie and...@operationaldynamics.com wrote: We can kiss gdk_pixbuf_get_pixels() goodbye, no problem, but I'm just curious what someone would replace it with... draw to a Cairo image surface, save that to a PNG and then load it and... oh wait. :) The idea is that what you do now is get the cairo surface and then cairo_image_surface_get-data() of course, frequently things that previously required pixel access would now be doable with cairo operations, which can only be a win for language bindings. As usually happens across the language barrier, we had to copy the array anyway, so I'm not really fussed where we get it from. Or, are we advised to tell developers no more access to an image's pixels? No, they just have to access them via the cairo surface Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf-cairo_surface_t conversion
On Fri, Sep 3, 2010 at 1:30 AM, Havoc Pennington h...@pobox.com wrote: Oops. I just put one in bugzilla ;-) I should have worked on the widget padding today I guess. https://bugzilla.gnome.org/show_bug.cgi?id=491507 You patch is much better than mine. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf-cairo_surface_t conversion
On Fri, Sep 3, 2010 at 3:22 AM, Soeren Sandmann sandm...@daimi.au.dk wrote: Not that it matters that much, but if you use cairo_mask() with the pixbuf data as both source and mask, the source as RGB24 and the mask as ARGB32, you could make cairo do the conversion from pixbuf to surface. That would likely hit an SSE2 or ARM NEON optimized code path in pixman. Interesting. But how would that deal with the fixed-endianness of pixbuf data vs the native endianness of cairo ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: pixbuf-cairo_surface_t conversion
Sorry this may be a very inept question: How will this effect integration with OpenGL. I know we use a lot of get/sets on pixels buffers; off screen rendering, textured (especial animated) and tricks. You want and need that raw data access. taking it way I think would also break GTKGLExt if I am not mistaken? As I have come to understand, most GL windows have a completely different context than the windowing system itself. Is cairo going to play nice? I mean with this: http://www.opengl.org/sdk/docs/man4/xhtml/glReadPixels.xml and this: http://www.songho.ca/opengl/gl_pbo.html Date: Fri, 3 Sep 2010 09:52:22 -0400 Subject: Re: pixbuf-cairo_surface_t conversion From: matthias.cla...@gmail.com To: sandm...@daimi.au.dk CC: gtk-devel-list@gnome.org; h...@pobox.com On Fri, Sep 3, 2010 at 3:22 AM, Soeren Sandmann sandm...@daimi.au.dk wrote: Not that it matters that much, but if you use cairo_mask() with the pixbuf data as both source and mask, the source as RGB24 and the mask as ARGB32, you could make cairo do the conversion from pixbuf to surface. That would likely hit an SSE2 or ARM NEON optimized code path in pixman. Interesting. But how would that deal with the fixed-endianness of pixbuf data vs the native endianness of cairo ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf-cairo_surface_t conversion
Hi, On Fri, Sep 3, 2010 at 11:35 AM, Shawn Bakhtiar shashan...@hotmail.com wrote: Sorry this may be a very inept question: How will this effect integration with OpenGL. I know we use a lot of get/sets on pixels buffers; off screen rendering, textured (especial animated) and tricks. You want and need that raw data access. taking it way I think would also break GTKGLExt if I am not mistaken? This pixbuf stuff shouldn't affect opengl (except by possibly eliminating a conversion, since a GL implementation is more likely to support the cairo format than the classic format, I think) Native-requiring widgets like GLExt and XEmbed and whatever will just be special cased in GTK someway and won't draw to a cairo context. This is an issue for Benjamin's rendering cleanup, but not related to pixbufs. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf-cairo_surface_t conversion
Hi, On Thu, Sep 02, 2010 at 07:57:44PM -0400, Matthias Clasen wrote: One downside that you've mentioned earlier is that with this approach, gdk-pixbuf grows a cairo (and thus libX11) dependency. That might inconvenience a few gdk-pixbuf users. But the one I know offhand, librsvg, already has a cairo dependency (via pango) anyway. So, probably not a big problem. For what it's worth, libgpod has a gdk-pixbuf dependency and no cairo dep, and people complain from time to time about that dependency (though that's mainly on distros where gdk-pixbuf is in the same package as gtk+, which will no longer be the case with gtk3). So I don't know how they will react to an additional cairo dep ;) On the other hand, a GdkPixbuf handling more formats than the current one would be really useful since for now it's not possible to easily transfer pixel data from a GdkPixbuf to a QImage (conversion is needed). Hopefully with the additional pixel formats that are suggested here, this will become easier. Christophe pgpSjhK7pqowt.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf-cairo_surface_t conversion
2010/9/3 Christophe Fergeau cferg...@gmail.com: Hi, On Thu, Sep 02, 2010 at 07:57:44PM -0400, Matthias Clasen wrote: One downside that you've mentioned earlier is that with this approach, gdk-pixbuf grows a cairo (and thus libX11) dependency. That might inconvenience a few gdk-pixbuf users. But the one I know offhand, librsvg, already has a cairo dependency (via pango) anyway. So, probably not a big problem. For what it's worth, libgpod has a gdk-pixbuf dependency and no cairo dep, and people complain from time to time about that dependency (though that's mainly on distros where gdk-pixbuf is in the same package as gtk+, which will no longer be the case with gtk3). So I don't know how they will react to an additional cairo dep ;) Well, since currently gdk-pixbuf comes inside Gtk+, and Gtk+ depends on cairo. In effect, you already depend on cairo. So in effect, you will have one dependency less, Gtk+. This should make your dependency-phobic users happy. On the other hand, a GdkPixbuf handling more formats than the current one would be really useful since for now it's not possible to easily transfer pixel data from a GdkPixbuf to a QImage (conversion is needed). Hopefully with the additional pixel formats that are suggested here, this will become easier. Christophe ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf-cairo_surface_t conversion
2010/9/3 Alberto Ruiz ar...@gnome.org: Well, since currently gdk-pixbuf comes inside Gtk+, and Gtk+ depends on cairo. In effect, you already depend on cairo. So in effect, you will have one dependency less, Gtk+. This should make your dependency-phobic users happy. This really depends, my distribution (Mandriva) puts gdk-pixbuf in a separate binary package. Thus cairo is needed to generate the gdk-pixbuf package because it's built as part of gtk+, but for the final user, there is already no such requirement as installing gtk+ to get gdk-pixbuf. Christophe ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf-cairo_surface_t conversion
Matthias Clasen matthias.cla...@gmail.com writes: On Fri, Sep 3, 2010 at 3:22 AM, Soeren Sandmann sandm...@daimi.au.dk wrote: Not that it matters that much, but if you use cairo_mask() with the pixbuf data as both source and mask, the source as RGB24 and the mask as ARGB32, you could make cairo do the conversion from pixbuf to surface. That would likely hit an SSE2 or ARM NEON optimized code path in pixman. Interesting. But how would that deal with the fixed-endianness of pixbuf data vs the native endianness of cairo ? It would only work on little endian CPUs. Soren ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf-cairo_surface_t conversion
Hi, I thought of another approach to this problem. Don't expose the pixbuf format at all; keep it as-is. However, add: gdk_pixbuf_get_cairo_surface() gdk_pixbuf_new_from_cairo_surface(cairo_surface_t *surface); Now, keep the cairo surface internally, strong-ref'd by the pixbuf. The pixbuf would have pixels == NULL. If someone does gdk_pixbuf_get_pixels(), then lazily create the old pixbuf format and keep that copy of the pixels around. Otherwise, never create the old format. If you create a pixbuf NOT from a cairo surface, then the reverse occurs. pixels != NULL, and a surface is lazily created and kept around if anyone does gdk_pixbuf_get_cairo_surface(). There are various APIs in gdk-pixbuf that call get_pixels() in the implementation. These would all be modified to use cairo_surface_t operations instead if the cairo_surface was set, and use the existing pixbuf code otherwise. So basically a GdkPixbuf can be either the old stuff internally, or a cairo surface internally, or have both cached, but with the same API either way. Some downsides: - two copies of the pixels would be kept for the two formats, in the case where we create a pixbuf in old format and then draw it. - APIs that modify the pixels might have to either modify both copies, or discard one of them to be lazily recreated - but wouldn't know which to toss - if you modified the surface pixels or the old-style pixels by hand, it would not affect the other format - this could be VERY surprising. The main upside would be zero new API, other than to/from cairo surface. The downside is that if something dumb is happening that ends up repeatedly converting pixels or keeping both pixel representations around eating memory, it would not necessarily be obvious. In this scheme, perhaps get_pixels, get_n_channels, get_colorspace, etc. (all the internal representation APIs) would be deprecated. You are supposed to port that code to get the surface and then mess with the cairo surface. Conceptually, GdkPixbuf's exposed pixel buffer representation becomes cairo_surface_t instead of colorspace, n_channels, get_pixels, etc.; GdkPixbuf is a cairo_surface_t wrapper instead of a guchar* wrapper. If/when get_pixels can be removed entirely, then the internal representation could always be cairo_surface_t _only_. The old constructors would immediately convert to cairo format. get_pixels() is the only reason external code would ever care about pixbuf internal representation. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf-cairo_surface_t conversion
On Thu, Sep 2, 2010 at 3:52 PM, Havoc Pennington h...@pobox.com wrote: Hi, I thought of another approach to this problem. Don't expose the pixbuf format at all; keep it as-is. However, add: gdk_pixbuf_get_cairo_surface() gdk_pixbuf_new_from_cairo_surface(cairo_surface_t *surface); Now, keep the cairo surface internally, strong-ref'd by the pixbuf. The pixbuf would have pixels == NULL. If someone does gdk_pixbuf_get_pixels(), then lazily create the old pixbuf format and keep that copy of the pixels around. Otherwise, never create the old format. Some variations of this theme (make GdkPixbuf a wrapper around a cairo surface) have been discussed. It is certainly attractive in terms of the amount of new api, and in terms of keeping the GdkPixbuf-based gtk apis intact. One thing I wonder about though: one of the big reasons to keep GdkPixbuf around is the image loaders. But in this scheme, every pixbuf thats loaded from a file would end up with an old-style internal representation, right ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf-cairo_surface_t conversion
On Thu, Sep 2, 2010 at 7:24 PM, Havoc Pennington h...@pobox.com wrote: Hi, Am I missing a big downside? One downside that you've mentioned earlier is that with this approach, gdk-pixbuf grows a cairo (and thus libX11) dependency. That might inconvenience a few gdk-pixbuf users. But the one I know offhand, librsvg, already has a cairo dependency (via pango) anyway. So, probably not a big problem. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf-cairo_surface_t conversion
On Thu, 2010-09-02 at 13:29 -0400, Havoc Pennington wrote: Each pixbuf could keep a cairo_surface_t which just pointed to the pixbuf pixels and that cairo_surface_t would be used in paint() or for other compositing/scaling/etc. kind of operations. Are you thinking of the loaders populating an image surface (and thus being in application memory) or populating an xlib surface (and thus being in X server memory?) People seem to have gone to a lot of effort over the years to find the right mix between GdkPixmap and GdkPixbuf and a fair bit of code has been written (using ie cairo_surface_create_similar()) to do caching, etc. Between your ideas here and Benjamin's work, I get the impression that the status quo is well and truly smashed [great!] but now I'm definitely vague about what's being loaded where, and when someone is going to have to worry [differently] about the performance implications of large copies between app and X server, etc. AfC Sydney signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf-cairo_surface_t conversion
Hi, On Thu, Sep 2, 2010 at 11:21 PM, Andrew Cowie and...@operationaldynamics.com wrote: Are you thinking of the loaders populating an image surface (and thus being in application memory) or populating an xlib surface (and thus being in X server memory?) I'm not proposing any change here. Loaders currently go to pixbufs (which are always application memory), and I'm proposing that when a pixbuf uses a cairo surface as representation, that cairo surface is always an image surface. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pixbuf-cairo_surface_t conversion
On Thu, Sep 2, 2010 at 7:24 PM, Havoc Pennington h...@pobox.com wrote:
I was thinking about the problem of wasting memory, writing to one
internal representation and not changing the other, etc. How about
this: we only keep one representation around. If you get_pixels we
drop the surface, if you get_cairo_surface we drop the old-style
pixels.
We deprecate get_pixels() which is the only call that can force the
old-style representation to be created. If you do use get_pixels(),
what's going to happen is that you do your pixel editing, and on the
next paint gdk_pixbuf_get_cairo_surface() will force conversion back
to cairo representation.
Here is an (untested) patch to implement this.
From 08eea58e9fb0d1b28392bca1d6ac320d3264bbb2 Mon Sep 17 00:00:00 2001
From: Matthias Clasen mcla...@redhat.com
Date: Fri, 3 Sep 2010 00:55:43 -0400
Subject: [PATCH] cairo_surface_t - GdkPixbuf conversion
---
configure.ac|2 +-
gdk-pixbuf/gdk-pixbuf-cairo.h | 39 +
gdk-pixbuf/gdk-pixbuf-private.h |4 +
gdk-pixbuf/gdk-pixbuf.c | 293 ++-
gdk-pixbuf/gdk-pixbuf.h |1 +
5 files changed, 336 insertions(+), 3 deletions(-)
create mode 100644 gdk-pixbuf/gdk-pixbuf-cairo.h
diff --git a/configure.ac b/configure.ac
index 5bf8248..498432d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -903,7 +903,7 @@ if test $cross_compiling = yes; then
fi
fi
-GDK_PIXBUF_PACKAGES=gmodule-no-export-2.0 gobject-2.0 gio-2.0
+GDK_PIXBUF_PACKAGES=gmodule-no-export-2.0 gobject-2.0 gio-2.0 cairo
GDK_PIXBUF_EXTRA_LIBS=$STATIC_LIB_DEPS $MATH_LIB $MEDIA_LIB
GDK_PIXBUF_EXTRA_CFLAGS=
GDK_PIXBUF_DEP_LIBS=`$PKG_CONFIG --libs $GDK_PIXBUF_PACKAGES` $GDK_PIXBUF_EXTRA_LIBS
diff --git a/gdk-pixbuf/gdk-pixbuf-cairo.h b/gdk-pixbuf/gdk-pixbuf-cairo.h
new file mode 100644
index 000..1e4b048
--- /dev/null
+++ b/gdk-pixbuf/gdk-pixbuf-cairo.h
@@ -0,0 +1,39 @@
+/* GdkPixbuf library - GdkPixbuf data structure
+ *
+ * Copyright (C) 2010 Red Hat, Inc.
+ *
+ * Author: Matthias Clasen mcla...@redhat.com
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 02111-1307, USA.
+ */
+
+#if defined(GDK_PIXBUF_DISABLE_SINGLE_INCLUDES) !defined (GDK_PIXBUF_H_INSIDE) !defined (GDK_PIXBUF_COMPILATION)
+#error Only gdk-pixbuf/gdk-pixbuf.h can be included directly.
+#endif
+
+#ifndef GDK_PIXBUF_CAIRO_H
+#define GDK_PIXBUF_CAIRO_H
+
+#include cairo/cairo.h
+
+G_BEGIN_DECLS
+
+cairo_surface_t *gdk_pixbuf_get_cairo_surface (const GdkPixbuf *pixbuf);
+GdkPixbuf *gdk_pixbuf_new_from_cairo_surface (cairo_surface_t *surface);
+
+G_END_DECLS
+
+#endif /* GDK_PIXBUF_CAIRO_H */
diff --git a/gdk-pixbuf/gdk-pixbuf-private.h b/gdk-pixbuf/gdk-pixbuf-private.h
index c060bd7..2ff22f2 100644
--- a/gdk-pixbuf/gdk-pixbuf-private.h
+++ b/gdk-pixbuf/gdk-pixbuf-private.h
@@ -31,6 +31,8 @@
#include glib-object.h
+#include cairo/cairo.h
+
#include gdk-pixbuf-core.h
#include gdk-pixbuf-io.h
#include gdk-pixbuf-i18n.h
@@ -73,6 +75,8 @@ struct _GdkPixbuf {
/* Do we have an alpha channel? */
guint has_alpha : 1;
+
+cairo_surface_t *surface;
};
struct _GdkPixbufClass {
diff --git a/gdk-pixbuf/gdk-pixbuf.c b/gdk-pixbuf/gdk-pixbuf.c
index 824e290..5ea3e04 100644
--- a/gdk-pixbuf/gdk-pixbuf.c
+++ b/gdk-pixbuf/gdk-pixbuf.c
@@ -29,6 +29,8 @@
#include stdlib.h
#include string.h
+#include cairo/cairo.h
+
#define GDK_PIXBUF_C_COMPILATION
#include gdk-pixbuf-private.h
#include gdk-pixbuf-features.h
@@ -178,10 +180,12 @@ static void
gdk_pixbuf_finalize (GObject *object)
{
GdkPixbuf *pixbuf = GDK_PIXBUF (object);
-
+
if (pixbuf-destroy_fn)
(* pixbuf-destroy_fn) (pixbuf-pixels, pixbuf-destroy_fn_data);
-
+if (pixbuf-surface)
+cairo_surface_destroy (pixbuf-surface);
+
G_OBJECT_CLASS (gdk_pixbuf_parent_class)-finalize (object);
}
@@ -441,6 +445,187 @@ gdk_pixbuf_get_bits_per_sample (const GdkPixbuf *pixbuf)
return pixbuf-bits_per_sample;
}
+static void
+convert_surface_to_pixels (GdkPixbuf *pixbuf)
+{
+ gint width = pixbuf-width;
+ gint height = pixbuf-height;
+ gint n_channels = pixbuf-n_channels;
+ gint gdk_rowstride = pixbuf-rowstride;
+ guchar *gdk_pixels;
+ guchar *cairo_pixels;
+ gint
