Gotcha with dynamically allocated surface sources.

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)

--
cairo mailing list
[email protected]
http://lists.cairographics.org/mailman/listinfo/cairo