[cairo] Re : Re : Re : Re : multithreaded bug in cairo on call to cairo stroke?
lerouxp at yahoo.ca
Wed Dec 15 07:27:12 PST 2010
ya pixman/simpleops is fine for me now
out of curiosity
so if i change the source to a random pattern just after i created the context
(in each threads)
would that force cairo to use a seperate source for each thread? and be kind of
because, i tried and it doesnt seems to work
i also tested your second patch (and without pixman/simplops)
works fine, with colors !
----- Message initial ----
De : Andrea Canciani <ranma42 at gmail.com>
À : Philippe Leroux <lerouxp at yahoo.ca>
Cc : cairo <cairo at cairographics.org>
Envoyé le : Mer 15 décembre 2010, 15h 50min 13s
Objet : Re: Re : Re : [cairo] Re : multithreaded bug in cairo on call to cairo
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
> 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
> 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
> 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.
More information about the cairo