Re: pixbuf<->cairo_surface_t conversion

[Havoc Pennington <hp pobox com>]

Hi,

On Thu, Sep 2, 2010 at 5:07 PM, Matthias Clasen
<matthias clasen gmail com> wrote:
> One thing I wonder about though: one of the big reasons to keep
> GdkPixbuf around is the image loaders. But in this scheme, every
> pixbuf thats loaded from a file would end up with an old-style
> internal representation, right ?
>

Loaders would have the option of using new_from_data() or
new_from_cairo_surface(). We would probably say new_from_cairo_surface
was preferred and port the interesting loaders to do that.

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 we
drop the surface, if you get_cairo_surface we drop the old-style
pixels.

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 that you do your pixel editing, and on the
next paint gdk_pixbuf_get_cairo_surface() will force conversion back
to cairo representation.

So the only "big fail" case is where you want to modify the pixbuf
pixels on every frame, or with some frequency. Those cases would just
have to be ported over to cairo_surface usage.

But hang on: gdk_cairo_set_source_pixbuf() currently converts on
*every paint*, *always*. So we have some evidence that this isn't even
a huge deal.

With the loaders, if they are unmodified then they create in
old-style, but on first call to get_cairo_surface we drop the old
style pixels. If they are updated to start from a surface, then the
old-style is only created if someone uses deprecated get_pixels.

I'm liking this approach. It's minimal code, and easy to make correct.
The "hard part" is purging get_pixels usage, but that is a performance
issue only, not a correctness one, and unlikely to be worse than
gdk_cairo_set_source_pixbuf already is.

Am I missing a big downside?

Havoc