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
Havoc Pennington hp at pobox.com writes:
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
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
On Fri, Sep 03, 2010 at 08:17:04AM +, Benjamin Otte wrote:
- We convert pixbufs every single time we paint them
This is important for performance considerations: We convert the
pixbuf to an image surface every single time we paint it. So
whatever we end up doing, it won't get any worse.
One website that has its own coordinators: http://webkitgtk.org/
It could deserve an update with the html skel that you have come up with.
My 2 cents
Mike
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
On 09/03/10 04:17, Benjamin Otte wrote:
- We convert pixbufs every single time we paint them
This is important for performance considerations: We convert the pixbuf to an
image surface every single time we paint it. So whatever we end up doing, it
won't get any worse. Also, no one has
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
Hi,
On Fri, Sep 3, 2010 at 4:17 AM, Benjamin Otte o...@gnome.org wrote:
- I'm not sure where to store contents
Naïvely, it doesn't make a lot of sense to store images that are only used on
the X server in client memory and upload them every time we need them. But
then,
closing a connection
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
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
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
its Python bindings to PyGtk if the devs over there are willing.
Yip, that would be fine in theory (PyGtk). Could you please point me to
where the PyGtk code for this lives? I presume you are talking about
just the ige-mac-integration GtkOSXApplication bindings in GitHub?
PyGtk will not see
On Sep 3, 2010, at 4:30 PM, John Stowers wrote:
its Python bindings to PyGtk if the devs over there are willing.
Yip, that would be fine in theory (PyGtk). Could you please point me to
where the PyGtk code for this lives? I presume you are talking about
just the ige-mac-integration
21 matches
Mail list logo
