On 2012-03-09 21:58, Krzysztof Kosiński wrote:
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.
Done. The main problem currently is the slicing/tiling that Inkscape does. This is similar for Gaussian blur. In principle these algorithms do not need to have overlapping tiles, as they "summarize" their history in a relatively small data structure, but we currently have no way to store these. Also, if we did, it would either complicate the implementation quite a bit, or we would have to always draw the tiles in the same order. But it would be a worthwhile endeavour to solve this, as essentially the current method transforms these O(n) (with n the size of the output) algorithms into O(n*m) algorithms (with m the size of the kernel).