[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


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 ? 





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