Re: Minutes of the GTK team meeting - 2010-09-07

[Havoc Pennington <hp pobox com>]

Hi,

On Tue, Sep 7, 2010 at 7:25 PM, Emmanuele Bassi <ebassi 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