Tue, 23 Oct 2007 02:08:57 -0200
"Felipe Sanches" <felipe.sanches@...> kirjoitti:
> I would like to say that I am not much confortable with the filters
> implementation I was working on some time ago. I need help to make it
> work better. I know that there are bugs that are due to my incomplete
> broken implementation, but I am stuck because I still don't
> understand exactly how the filters infrastructure work
> I don't know how to properly implement zooming, nor rotation. Look at
> feturbulence. It does not rotate correctly.
You don't need to implement rotation as such, it's a feature handled by
NRFilter, NRFilterSlot and NRFilterUnits. I've now (revision 16326)
added the TRAIT_PARALLER rendering hint to every filter primitive,
where it makes a difference, if object's x- and y-axis point to
different directions than x- and y-axis of input image.
Put otherwise, every filter primitive that has a get_input_trait
-method, that returns TRAIT_PARALLER, will only receive non-rotated and
non-skewed images as input. I've now added that to every filter, that
seemed to need it. Including turbulence.
> I also don't know whether I am using the best approach. I have used a
> pixmap buffer where I render the feturbulence effect and I have an
> "updated" flag. Then, if some parameters are changed (on
> sp-feturbulence.cpp) I set this flag to false. When the render method
> is called, it checks the updated flag and only recalculates the
> effect when the updated flag is false (and then sets it to true).
> When zooming, I will have to free the current pixmap buffer and create
> another one of greater size and recalculate it. It seems to me that
> zooming will have great slowdowns if I continue working that way. Any
> body know any kind of "design pattern" that I should be using to
> implement the zooming? I feel that I am walking the wrong way. And I
> keep scared about the possibility of not being able to fix these
> filters before next release deadline. So, what I mean is that I
> really need help to make this stuff work alright.
I'd think, the best solution is to just re-render the effect in the new
It seems, that turbulence would benefit much from changing the render
render(FilterSlot &slot, Matrix const &trans)
render(FilterSlot &slot, FilterUnits const &units)
FilterUnits contains the matrix, render method receives now, but also
much more. Especially helpful here would be the fact, that FilterUnits
can be made to give the pixel size of the to-be-rendered area. This
way, turbulence render can easily determine, if its cached pixblock is