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
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,
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
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
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
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
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
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
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.
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
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
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
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
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.
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
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
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
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,
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
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
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.
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
22 matches
Mail list logo
