2011/3/13 Vladimir Savic <vladimir.firefly.savic@...400...>:
Maybe I misunderstood the concept behind filter rendering, but what about joining efforts with GEGL guys and using that library? I guess it will develop faster, both big apps that would use it (Inkscape and GIMP) will benefit from joined development, bugs will be fixed faster, etc. If I understand correctly, GIMP will use GEGL for pixel computations too and pass the resoult to cairo for drawing on canvas.
GEGL is not very well suited to interactive vector drawing. However, there is a standalone GEGL graph renderer and we could make an output plugin that saves such a graph.
2011/3/13 the Adib <theadib@...1439...>:
Is there any plan how we will speed-up performance in future. I mean:
- fast (visual) response to the user
- fast rendering
I know that we have:
- tiling the image into pieces to decrease user response time
- add OpenMP to filter functions
On the roadmap is conversion to cairo. But cairo does not render filters at all. I read that LLVM could speedup when generating the filter code .....
The trunk only has OpenMP in Gaussian blur. The Cairo branch has it for all filters. But the main problem is with filters that depend on a lot of data, such as large radius Gaussian blur. Each tile is rendered separately, and large portions of the image have to be re-rendered over and over. If we can cache the intermediate data between tile renderings, it would give us a massive speedup.
An OpenCL backend for Cairo, or improvements in its OpenGL backend, would be the ultimate solution for modern systems. We could then use the GPU to compute the filters.
Regards, Krzysztof