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

[Andrea Canciani]

On Thu, Dec 16, 2010 at 6:54 PM, Philippe Leroux <lerouxp at yahoo.ca> wrote:
>
>
>>Additional details:
>>The idea in this case would be that you add graphical operations
>>sequentially (thus the sequence is ordered, well defined), just as usual, but
>>cairo and pixman actually perform them in parallel.
>>This would be a better use of your parallel processing power, because
>>it would still
>>guarantee that the result is the expected one, yet all the cores would
>>be used to
>>compute the image. Moreover it would also improve the performance of existing
>>applications ;)
>
>>Andrea
>
>
> absolutely, with go it is very easy to do so, i just need to define an
> asynchronus channel and send cairo operations on it
> but, euh, how does cairo and pixman perform this in parallel?
> for instance, each core renders part of the images or something?

Cairo and pixman don't do it yet, but the two main possibilities are:
- split images and composite one tile on each core
- get a tree of compositing operations (like "(A SOURCE B) OVER C)" ) and
  do the compositing operations in parallel
These two approaches can possibly be combined.

>
> is that already possible? or some feature planed for future development
It is not really planned... more like put in the heap of future improvements.

>
> i'd be very interested to help

Most of this parallelization code would actually be in pixman, so you might
want to ask on pixman at lists.freedesktop.org as well, but AFAICT so far
there has just been some speculation on what might be possible ways to
do it. No actual planning or implementation.

I don't want to discourage you from contributing to cairo/pixman, but I think
that this task would be quite complex (in particular if you want to ensure that
no regressions happen on single-core processors), anyway having a look at
the problem won't hurt.

If you look through the archives of pixman you will also find some people
working on an OpenCL backend for pixman, which is a very generic approach
to do the same task (but I've been warned that the setup/teardown costs of
OpenCL are very high, so making it faster than current solution might be
hard as well).

Andrea