[cairo] Gotcha with dynamically allocated surface sources.
Cope, Phil (GE Energy)
phil1.cope at ge.com
Wed Sep 28 08:31:25 PDT 2011
I have come across what seems to be a bug, or at least a bit of a
"gotcha". My C code is essentially
char* imageData = malloc(size);
imageSurface = cairo_image_surface_create_for_data(imageData,
cairo_set_source_surface(cairoCtxt, imageSurface,(double)x, (double)y);
/* Fix/Workaround goes here */
This code works fine when given a cairoCtxt opened on an xlib_surface or
a win32_surface, but NOT a pdf or internal surface. In these latter
cases the image data appears garbled.
The reason for this, is that (irrespective of the surface) the
imageSurface reference count is 1 at the free() - because it is still
registered as the source in cairoCtxt, and so I guess strictly speaking
I am not at liberty to call the free() statement. It would appear that
for PDF surfaces, at least, this is significant.
The solution/workaround is to insert the line
at the /* Fix/Workaround goes here */ comment (perhaps a
cairo_surface_flush(cairo_get_target(cairoCtxt)) would work too ?? ).
Presumably by explicitly changing the source, this forces the PDF
surface to execute whatever it hasn't done already with the existing
source, and - of course - the reference count drops to 0. It seems a
bit obscure to have to do this ?
There doesn't appear to a way of registering a callback to be executed
when the surface reference count drops to zero, so I wonder how else
application programmers are supposed to handle this situation ?
Phil Cope (Senior Software Engineer, Software Solutions Group, GE)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cairo