After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 395578 - Request: gdk_pixbuf_to_cairo_surface()
Request: gdk_pixbuf_to_cairo_surface()
Status: RESOLVED WONTFIX
Product: gdk-pixbuf
Classification: Platform
Component: general
git master
Other Linux
: Normal enhancement
: ---
Assigned To: gdk-pixbuf-maint
gdk-pixbuf-maint
Depends on:
Blocks:
 
 
Reported: 2007-01-11 21:35 UTC by Chris Wilson
Modified: 2018-05-01 12:43 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Export the pixbuf to cairo_surface creation routine. (5.06 KB, patch)
2007-01-11 21:36 UTC, Chris Wilson
none Details | Review

Description Chris Wilson 2007-01-11 21:35:05 UTC
A common necessity I have is to reuse the cairo_surface corresponding to a GdkPixbuf and a desire not to rebuild it every time. So to avoid continually cut'n'pasting the code from gdkcairo.c can we export the surface creation routine?
Comment 1 Chris Wilson 2007-01-11 21:36:11 UTC
Created attachment 80073 [details] [review]
Export the pixbuf to cairo_surface creation routine.
Comment 2 Havoc Pennington 2007-01-11 21:47:57 UTC
It might be nice to have this take an area to convert, or alternatively maybe have an "rgb(a) to surface" routine taking just a byte array, rowstride, etc. instead of a pixbuf then build the pixbuf convenience routine on that.

The docs should be clear about whether the function returns a new surface each time, or a shared (and thus effectively read-only) surface.
Comment 3 Havoc Pennington 2007-01-11 21:48:32 UTC
(if it returns a shared/cached surface there probably has to be a way to invalidate the cache if you modify the pixbuf)
Comment 4 Havoc Pennington 2007-01-12 00:23:42 UTC
btw, I did also need to cut-and-paste this code, so vote for the feature or some related feature.

It's possible the need for this code is primarily that to load an image you have to load it as a pixbuf and then convert, it might be nice to add some direct cairo_surface image-load APIs bypadding pixbuf entirely (and also make gdk-pixbuf-csource able to output the cairo ARGB format). Another useful thing might be a surface option in GtkImageType.

One way to add direct cairo surface load to gdk-pixbuf might be to add a cairo-identical pixbuf format, though I'm sure there's tons of code that assumes the pixbuf is in RGB/RGBA format, so I don't know if that would really work out well.
Comment 5 Behdad Esfahbod 2007-01-12 06:37:23 UTC
Move the loaders to cairo?   I know many people won't like it, but much code seems to be duplicated in gdkpixbuf and cairo.  Scaling, anyone?
Comment 6 Havoc Pennington 2007-01-13 00:03:33 UTC
thinking out loud...

I think it's nice to keep support for loading lots of formats separate from cairo, since the loaders are really a large chunk of code conceptually separate from cairo's focus. gtk could never deprecate the gdk-pixbuf loaders anyway. cairo does have a minimal png loader but the idea I gather was to leave it at png only.

Really using gdk-pixbuf to load is fine, the only downside is having to copy/convert into a cairo surface, so if there were some zero-copy way to load in the cairo format in gdk-pixbuf, that would solve the issue...
(at first the zero-copy could just be hypothetical and allowed by the API, while really converting, and then later maybe some loaders could support loading to ARGB directly as an optimization)

A GdkPixbuf object could support both argb and rgba internally and magically convert depending on what's requested, the problem with GdkPixbuf though is gdk_pixbuf_get_pixels() which wrecks the opacity of the object - it's hard to keep magic caches of any kind because someone can write to the pixels without the pixbuf object finding out about it. It might work OK though to just set a "tilt bit" if get_pixels() is called, and be magic as long as nobody has called that function. Then try to remove all uses of get_pixels() from GTK proper.

hmm, another approach might be to try and add an image loader API that had only cairo_surface_t in it, with the idea that gdk-pixbuf.h would be deprecated. Initially, the new API would be implemented with gdk-pixbuf as the backend, but "someday" pixbuf could be deprecated.

That might be the nicest approach, so new code could ignore pixbufs entirely, even though it would be using them in the background. All GTK APIs that use pixbuf would need duplicating in a cairo_surface_t version however.

Comment 7 Soren Sandmann Pedersen 2007-01-13 02:07:43 UTC
Another possibility is to simply make Cairo (or pixman really) support non premultiplied rgba. 
Comment 8 Behdad Esfahbod 2007-01-13 07:46:48 UTC
(In reply to comment #6)
> thinking out loud...
> 
> I think it's nice to keep support for loading lots of formats separate from
> cairo, since the loaders are really a large chunk of code conceptually separate
> from cairo's focus. gtk could never deprecate the gdk-pixbuf loaders anyway.
> cairo does have a minimal png loader but the idea I gather was to leave it at
> png only.

To give some context for proposal, it's being discussed on cairo list right now about finding a way to load images and use with cairo such that it allows backends like PDF to embed them as is, without decompress+recompressing them:

  http://lists.freedesktop.org/archives/cairo/2007-January/009096.html

And since there are backends that need to show them image (like the image backend), cairo should be able to decode those images.  Hence, moving them down...

As for being a logically separate unit, I think it's not much different from pixman.  Currently cairo includes it internally and doesn't expose it.
Comment 9 Hubert Figuiere (:hub) 2009-05-10 03:33:24 UTC
I had to reimplement that myself, to generate an icon on the fly for a GtkStatusIcon.
Comment 10 Tobias Mueller 2017-02-17 09:41:31 UTC
It's been a while...  Is this functionality still desired?  Does the patch still apply?
Comment 11 Emmanuele Bassi (:ebassi) 2018-05-01 12:43:57 UTC
We're not going to add this functionality to GdkPixbuf; ideally, GdkPixbuf should not have anything to do with the graphics subsystem. We're also moving away from GdkPixbuf in our API for GTK 4, and either use opaque buffers that map to rendering API like Vulkan and OpenGL; or use Cairo surfaces directly.