On 5/30/06, Niko Kiirala <niko@...> wrote:
> Here is the first test on rendering filter effects. It applies constant
> gaussian blur to every rendered object of type NRArenaShape. This is
> mostly to test the speed of rendering filter effects in real time.
Thanks, that's a great start!
I have given you (kiirala on SF) SVN access and created a branch for
filter effects, check out with:
svn checkout https://svn.sourceforge.net/svnroot/inkscape/inkscape/branches/svg-filters
and please commit your change to it.
Hugo, now it's your turn :) Please use this branch also for your part
of the work.
> This test does not apply blurring to all types of objects - that would
> result in blurring the object, blurring the layer the (already
> blurred) object is on, etc.
Right. Later we'll blur any kind object for which the filter is
specified, but for testing it's OK.
> The biggest problem at the moment seems to be transparent areas
> appearing, when an object is drawn in several smaller pieces rather than
> in one piece. Guess the object needs to be drawn on a larger buffer thet
> is larger than the result will be - thus allowing blurring to take in to
> account the pixels outside the actual area, we are rendering to.
Another related problem is that the blurred edges are cut off by the
bbox of the object. So, blurring must extend the rendering bbox of
NRArenaItems by its deviation radius, so that it covers all of the
As for rendering in stripes, yes, we may want to disable this for
those objects that have filters applied. Another solution might be to
extend the stripes and make them overlap, also by the deviation
radius. I don't know which is easier to implement and which is faster;
For the purpose of testing, could you please make the blur effect take
the radius from the same filtertest prefs value, instead of the fixed
value of 2?
More importantly, I noticed that the radius is interpreted in screen
pixels, i.e. it stays the same (and therefore changes relative to the
size of the object) when you zoom in or out. I think this is
incorrect: the spec says that with userSpaceOnUse (which is the basic
mode we should strive to implement), the lengths are interpreted in
the local coordinate system, which includes zoom. In other words, the
lengths must be considered to be in px units, not screen pixels, and
you need to pass the current display transform (i.e. zoom, but later
it may include not only zoom but also e.g. rotation) to the filter and
make the filter multiply its lengths by the zoom factor.
As for speed, I noticed you have an operation with a double (sum) in
the innermost loop. I think it might become noticeably faster if you
implement this critical calculation entirely in integers. Can you do
And finally, can you please resend that diagram you sent a couple days
ago but in SVG? I don't have Dia :)
Thanks again, and please keep the great work! I'm watching the filters
branch with great excitement :)
Inkscape. Draw Freely.