W dniu 8 marca 2012 19:42 użytkownik Jasper van de Gronde <th.v.d.gronde@...528...> napisał:
Is there any particular reason that the morphology filter uses something called a "surface synthesizer" (or something along those lines)? Its time complexity currently depends on the structuring element size, and I wanted to fix that, but to do that I need to be able to keep some history, as well as delaying the output until enough data has been gathered. Is this possible at all within this scheme? If not, is it okay if I just copy-paste ink_cairo_surface_synthesize - gut it - and write a few simple loops? (Or am I missing something?)
I used this approach to abstract away the OpenMP multithreading support. It works well for the majority of filters, but I admit it's not optimal for morphology. You can ignore ink_cairo_surface_synthesize if you implement multithreading yourself. For example, Gaussian blur does not use these templates at all.
You can also try implementing the triple box blur approximation for Gaussian blur, which should be a lot faster than the current approach. The details are in the SVG filter specification. I tried doing this some time ago, but the result was all wrong and I couldn't figure out why.
Regards, Krzysztof