I committed (actually a week ago) some improvements in filtering framework. The main part of this improvement is the new NR::FilterUnits class, which provides tools for handling different coordinate systems in filters.

Another big part is moving code for preparing pixblocks from NR::Filter to NR::FilterSlot, where it more conveniently belongs. This means, that now all pixblocks a filter primitive can receive are in same coordinate system. (this fixes bug #1768003)

Filter primitives can affect, what this coordinate system is, by overriding the get_input_traits function. Example from gaussian blur:

FilterTraits FilterGaussian::get_input_traits() { return TRAIT_PARALLER; }

At the moment, the only other possibility is TRAIT_ANYTHING, which is the default, and specifies that filter doesn't care, what the coordinate system is like. (feBlend and feComposite are like this, for example)

TRAIT_PARALLER means, that x- and y-axis of the object must be paraller to x- and y-axis of the input image. For example, feGaussianBlur requires this, as the deviation is specified along object x- and y-axis.

Only FilterGaussian has this implemented now, it should be implemented in other filters, that need it.

I made it use bitfields and called it traits, because I think that this can have a wider use. For example, many filters need 32-bit RGBA images with premultiplied alpha as inputs. We could specify this as trait and move the handling code from the filter primitives to FilterSlot.

Also, I'm thinking, that Filter::render and FilterPrimitive::render should be changed to take FilterUnits as an input instead of Matrix. This would give these functions more tools to figure out, where things should be placed, how large the affected area should be, where the bounding box corners are etc.

Helper functions for calculating distances, transforming points from user coordinates to image coordinates etc. can also be added to FilterUnits, so that they don't need to be implemented in filter primitives.