Matthias Clasen writes:
> On Thu, Sep 2, 2010 at 7:24 PM, Havoc Pennington 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 w
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
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 b
Havoc Pennington 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 surf
2010/9/3 Andrew Cowie
> 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_imag
2010/9/3 Alberto Ruiz :
> 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
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 wors
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
http://mail.gnome.org/mailman/listinfo/gt
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 compl
Hi,
On Fri, Sep 3, 2010 at 4:05 AM, Andrew Cowie
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
Hi,
On Fri, Sep 3, 2010 at 4:17 AM, Benjamin Otte 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 to the X s
On Fri, Sep 3, 2010 at 1:30 AM, Havoc Pennington 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.
___
gt
On Fri, Sep 3, 2010 at 3:22 AM, Soeren Sandmann 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
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 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
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 h
2010/9/3 Christophe Fergeau :
> 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 on
2010/9/3 Alberto Ruiz :
>
> 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
Matthias Clasen writes:
> On Fri, Sep 3, 2010 at 3:22 AM, Soeren Sandmann 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 pixb
> 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 up
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 Gt
21 matches
Mail list logo
