[cairo] Re : Re : Re : multithreaded bug in cairo on call to cairo stroke?

[Andrea Canciani]

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
work.

>
> 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
performing, so
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
cairo_set_source*()
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.

Andrea
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image-no-cache.patch
Type: application/octet-stream
Size: 1363 bytes
Desc: not available
URL: <http://lists.cairographics.org/archives/cairo/attachments/20101215/8cba901c/attachment.obj>