[cairo] Gotcha with dynamically allocated surface sources.
Cope, Phil (GE Energy)
phil1.cope at ge.com
Wed Sep 28 08:31:25 PDT 2011
Hello,
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_FORMAT_RGB24,
width,height,
stride);
cairo_set_source_surface(cairoCtxt, imageSurface,(double)x, (double)y);
cairo_paint(cairoCtxt);
/* Fix/Workaround goes here */
cairo_surface_destroy(imageSurface);
free(imageData);
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
cairo_set_source_rgb(cairoCtxt, 1.,1.,1.);
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 ?
Cheers
Phil Cope (Senior Software Engineer, Software Solutions Group, GE)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cairographics.org/archives/cairo/attachments/20110928/ecb9df5b/attachment.htm>
More information about the cairo
mailing list