On 2010-09-05 12:35, Abhishek Sharma wrote:
... I would love to move forward in the area, but I will be needing some push(in terms of startup) to get started. Like the first and foremost question that lies ahead of me as a wall is, "What is the area of the code that is possible to be parallelized and how much can it affect the performance??" Second question is, What approach should be taken to parallelize the stuff??
As explained earlier one possibility would be to optimize Cairo. This is NOT part of the Inkscape code base in any way, but any work on this library will (in the near future) directly be able to impact not only Inkscape, but also other open-source projects. As it is largely a rasterizing library it should not be too hard to find things to parallelize, but you should really contact the Cairo folks for that.
Most serial algorithms when implemented in parallel totally change their appearance. So will that be OK or not?? There are other hurdles but it would be better to first proceed forwards with snacks and then go the main feast. I hope the developers will mark their attention to this and kindly come to start this discussion.
Inkscape has a number of filters that can be easily parallelized (in fact, Gaussian blur already uses a crude, but effective, form using OpenMP). They are all located in the src/display directory as nr-filter-*.cpp. You're free to pick one and parallelize it (there all have a pretty obvious "render" function). Quite a few of them would be trivial to parallelize, so have a look if you can find one with which you feel comfortable modifying and have a go. If you run into trouble you can always present your problem here.
To write a patch for Inkscape all you have to do is checkout the source, modify it to suit your needs, make a patch file (bzr diff -p1 for example) and post it here and/or to the bug tracker. You don't need our permission or approval to get started. (There is information on the Wiki on how to check out the code and build it.)