GNOME Bugzilla – Bug 645817
GeglMatrix is not introspectable by Gobject Introspection
Last modified: 2011-04-11 12:21:34 UTC
This because multi-dimensional arrays are currently not supported, see bug 567993 A possible workaround is to wrap the gdouble [3][3] in an opaque struct, and change the gegl_matrix functions to accept a pointer to such a struct. New matrices could be constructed using a new function that takes 9 doubles, and set/get_data functions could allow access to the data array. This would introduce an ABI break. Another alternative is to change the 3x3 array to a single dimension array with 9 elements. This should be supported by GI and might not be an ABI break (have to consult a C reference).
Taking. Will change to a struct matching GimpMatrix2/3: http://developer.gimp.org/api/2.0/libgimpmath/libgimpmath-GimpMatrix.html
Fixed in http://git.gnome.org/browse/gegl/commit/?id=ffe0549a8c64172c28fe16b8c48d1ee967b87b99
The commit referenced above introduced few new memory leaks. In operations/{affine/affine,external/{path,vector-{fill,stroke}}}.c there are calls to 'gegl_matrix3_new' (and g_new(GeglMatrix2, 1)) not paired with the corresponding g_free. Not that it is necessary to allocate the matrix on the heap, but in that case, when done, it is better to release the memory, since these operations are shared objects and not plug-ins executed in a separate short living process. BTW in operations/external/{path,vector-{fill,stroke}}.c there is shortage of calls to 'cairo_surface_destroy' and 'cairo_destroy' as well.
Thanks, you are very right. How sloppy of me. Fixed in http://git.gnome.org/browse/gegl/commit/?id=d5ed2b9533daa998de291a6241a1d5f080852dbd Also pushed documentation fixes to make it clear that gegl_path_set_matrix copies the matrix. Could you provide a patch for the cairo context/surface leaks and attach it to a bugreport?
I don't think it is worth, probably it is dead code, I've seen there's a git branch 'paint-system' that seems the future of these operations. Anyway the memory leak is only a problem among many others, taking the function 'process' in operations/external/path.c as reference: 1) Each thread has its own local GStaticMutex. Unless a mutex is not needed there, that's wrong because locking it will not synchronize anything. 2) The input GeglBuffer loses its high bit depth as soon as gegl_buffer_linear_close performs the conversion "B'aG'aR'aA u8" -> "RaGaBaA float" 3) It is missing a call to cairo_surface_finish or cairo_surface_flush before reading the output of cairo_fill. 4) the babl_format ("B'aG'aR'aA u8") corresponding to cairo_surface's format is endianness-dependent. 5) before cairo_set_source_rgba there is no color conversion: a path having the same mid-tone stroke and fill color is rendered with two different colors. 6) if you call cairo_set_fill_rule in 'process', you should in 'detect' as well.
please open a separate bug report for the cairo op issues, they are not dead code - but discussion of them do not belong in this bug report.