On Thu, Sep 2, 2010 at 1:20 PM, Matthias Clasen <matthias.cla...@gmail.com> wrote: > Thanks for diving into this. > > As a datapoint, here is the current GTK/GDK api that directly involves > GdkPixbuf: >
Cool, thanks. In a quick grep, basically nothing has been changed to pass around cairo_surface_t as a representation of "an image" So the current situation really is that images are pixbufs it seems like. I don't know. I know it isn't The Plan, but I'd sort of lean toward *not* trying to change all pixbufs to cairo surface. I sort of like the idea that cairo objects are used just during the paint(), when they are created and immediately tossed. But for persistent objects, a GObject is nicer. Not to mention avoiding all the deprecations and portings and stuff. 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. In this plan, Loader and Animation would not be deprecated. However, arguably "classic pixbuf format" and the stuff in gdk-pixbuf that only works on it (scaling, compositing, saturate_and_pixelate, etc.) would all be deprecated; to do that kind of stuff, you'd use cairo. Maybe gdk-pixbuf would grow some nice convenience functions that used cairo internally, i.e. a scale_simple() is still nice to have, and it would use cairo to work on the cairo formats. (hmm. that's one approach - add gdk_pixbuf_get_cairo_surface(); then make all the pixbuf scaling/compositing APIs basically do "if cairo format, use cairo, else use old pixbuf code" - so the pixbuf APIs become convenience wrappers around cairo operations) Havoc _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list