On 5/30/06, Niko Kiirala <niko@...1267...> 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 <dir>
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 blurred object.
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; please experiment.
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 this?
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 :)