[cairo] Re : Re : Re : multithreaded bug in cairo on call to cairo stroke?
ranma42 at gmail.com
Wed Dec 15 06:50:13 PST 2010
On Wed, Dec 15, 2010 at 2:59 PM, Philippe Leroux <lerouxp at yahoo.ca> wrote:
> oops, had not seen attachment
> just tried it
> it works
As you pointed out, it has a problem, but the new patch (see attachment) should
> i also tried the version of pixmap with safe simpleops (without patch you sent:
> with orginal libcairo)
> and it works
pixman/simpleops should provide better performance than the attached patch,
so you should probably use it, if it is a viable option.
> the patch seems to cut short some cairo optimization or something?
Yes, the patch makes cairo-image not use a cache for solid colors.
> just to note, that in my case, there seems to be no difference in speed from one
> solution or the other
The simpleops library should save some locking (required to have threadsafe
mallocs), buf the hot spots depend on the operations you're actually
you can actually get the same performance.
> by source, you mean cairo_surface?
No, a cairo_pattern. Even if you don't explicitly create cairo_patterns,
whenever you do a drawing operation (stroke, fill, paint, mask...) cairo is
actually using a cairo_pattern.
By default it's using a solid black pattern, but when you call
functions, cairo changes the source for the context you specify.
> because each of my "goroutine" as they call it, call to lockOSthreads,( to
> force them to be on an os thread and not multiplexed on different threads)
> creates its own cairo_surface (cairo_image_surface_create) then the context
> (cairo_create(the surface)), draws, save image, clears, draw again save.....
> did i miss something here?
> am i doing something wrong?
> do you think that the go language may not be correctly locking the goroutine on
> an os thread?
Since the patch fixed the crash (and the new patch hopefully also makes colors
look correct), it's likely the problem is just in pixman refcounting
(or cairo usage
of pixman). Based on what you said about your code and on its behavior, I think
that both go and your code are doing the right thing.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1363 bytes
Desc: not available
More information about the cairo