Hi, On Tue, Sep 7, 2010 at 7:25 PM, Emmanuele Bassi <eba...@gmail.com> wrote: > - possible addition pre-3.0: surface ↔ pixbuf conversion functions in gdk >
Incidentally, these should probably be in gdk-pixbuf (to avoid cairo dep they could just go to guint8*). The main use I guess is say in Clutter or other cairo-but-not-GdkDrawable contexts. btw, I think the patch on https://bugzilla.gnome.org/show_bug.cgi?id=491507 provides the proper API that we'd also want if cairo adds support for "classic pixbuf" format. The patch on the bug is having to keep a surface for cairo format, and a manual byte buffer for old pixbuf format. But if cairo had old pixbuf format, you'd just keep a surface, period, done. Either way I think you want new_from_cairo_surface(), get_cairo_surface(), and you want to do the deprecations of get_pixels(), GdkColorspace, and related stuff. I'd say a great path would be to put in the patch on 491507 - possibly in "max compatibility" mode, i.e. always keep the pixel buffer around and just pay the memory cost - and then when new cairo comes out, you could 100% compatibly drop the pixel buffer and have *only* a cairo surface representation. If cairo does not add classic pixbuf format (I'm still not sure it should), then things are trickier, because with my patch on 491507 you have to choose between definitely 100% compatible but uses 2x memory until all apps stop calling get_pixels() and new_with_data() and new(), or 98% compatible but avoids 2x memory sooner. Still, assuming a cairo dependency is OK, I think the API (and the deprecations) in this patch are right. The implementation depends a bit on how picky we want to be about breaking apps in super obscure cases, and what cairo ends up doing. If a cairo dependency is not ok, then just simple convert-to-from-guint8-in-cairo-format is one option, or my original patch, http://mail.gnome.org/archives/gtk-devel-list/2010-September/msg00022.html, is a kind of middle ground between "just add a very raw pixel convert function" and "swap internal pixbuf representation to cairo" - some advantages of that original patch include: - no cairo dependency - Loader could then grow a property for the desired format, and apps could opt in to load in cairo format - if/when a cairo dep was added and cairo had "classic pixbuf" format, pixbuf could be transparently switched to keep a cairo surface internally The disadvantages vs. the patch attached to https://bugzilla.gnome.org/show_bug.cgi?id=491507 might include: - does not automatically convert any existing pixbufs without changing apps - does not cache a cairo surface on each pixbuf, gdk continues to convert on each paint - does not deprecate get_pixels() (since there's no cairo surface to use instead) - can't draw to the pixbuf with cairo (until cairo supports pixbuf format) Overall I think adding new_from_cairo_surface(), get_cairo_surface(), and deprecating get_pixels/new_from_data/&friends, is the right thing to do, whether or not cairo gets classic pixbuf format. And the patch is pretty much ready. (and tunable for desired compatibility vs. efficiency tradeoff) But I do understand if people don't have time to dig in for 3.0. Havoc _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list