Re: pixbuf<->cairo_surface_t conversion

[Havoc Pennington <hp pobox com>]

Hi,

On Fri, Sep 3, 2010 at 4:17 AM, Benjamin Otte <otte gnome org> 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 server does invalidate the pixels of an Xlib
> surface, but not of an image surface. And storing it twice is needless dulicate
> memory usage. So no idea where to best store pixel data.

When GdkPixbuf was invented the sentiment was certainly that storing
contents on the server was wrong. I can't rattle reasons offhand.

For just icons and things, doing the shared memory copy to the server
on paint ought to be cheap, I guess. If you have some giant image,
then you have to be more clever (I would assume things like EOG are at
least mildly clever, though I don't know)

In any case I don't think it really works to make GdkPixbuf able to
have any type of cairo surface, because the semantics become too
undefined; you might not be able to get at pixels, might not have a
fixed size, etc. I think for GdkPixbuf the cairo surface should be
defined to be an image surface. This is what I did in the patch.

Maybe there's some type of cache facility for image surfaces that are
kept on the server for fast paint, I don't know.

> - Cairo surfaces have no size, and can change it
> In general, Cairo surfaces have no size. That is why there is no call to
> cairo_surface_get_size(). (This might change in the future, but hasn't yet.)

Image surfaces have a size though

> - We lose precision if we use Cairo formats
> Premultiplied formats have less precision then unpremultiplied ones; the
> conversion from unpremultiplied to premultiplied is not lossless. (0x40FFFFFF
> and 0x40FEFEFE are both stored as 0x40404040 unpremultiplied.) So loading, then
> saving a PNG might result in a different image being stored. Not sure that is a
> good idea.

I wasn't aware of this and it would break the patch as I have it,
presumably. (Or any scheme where we don't always keep the original
classic-style pixbuf pixels.) By "break" I guess I mean "some pixels
would change from FE to FF by themselves" which may not be a bad
enough problem to keep around image data in a weird format and keep
copying it, especially when we have to convert FE to FF at paint time
anyway.)

yeah, actually if we're already going FE to FF at paint time then I
guess it doesn't matter if we do it earlier when we store the pixels.

Havoc