11:09 p.m.
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.
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.
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.
--
Niko Kiirala
niko@...1267...
http://niko.kiirala.com/
1:01 a.m.
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 :)
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
1:06 a.m.
On May 30, 2006, at 9:01 AM, bulia byak wrote:
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?
Oh, just be sure to measure performance before and after things like
this (and with and without optimization turned on).
With the introduction of the Pentium processor many operations became
faster with floating point than with integer. So one needs to
actually measure things like this.
(not measuring performance of changes intended to speed things is an
easy trap to fall in, but studies have shown that programmer
intuition in regards to optimization is wrong the vast majority of
the time)
3:55 a.m.
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.
Hi,
First post to the list, and I want to thank everyone that makes Inkscape
such a great app.
Just an idea here : would it be possible to create an object with
blurring properties (as well as a certain amount of transparency) on the
objects below it?
That could have very interesting application for artistic drawing
(simulate a piece of glass, a lens
, etc). Even though the same result could be done by applying a blur
effect on a certain area, this would make it far more souple (one could
freely move the object, resize it, etc...
Just an idea (and I'm not a programmer, so I can't do it :) )
Cheers,
Loïc
5:49 a.m.
Hi Niko,
Now that blurring works fine, I think next up is some rearchitecturing
in your part. You are creating and deleting the filter object twice
per each call to nr_arena_item_render, once to get the extent from it
and then to do the actual render. This is inefficient. I think filter
object must be a property of NRArenaItem, created upon demand (i.e. on
first render) and then reused for all subsequent renders of that item.
Similarly, gaussian blur filter should create its x and y kernels on
demand and not regenerate them upon each render.
However, we need to update the filter if some of its parameters
change, and we need to get the list of filter primitives and their
parameters to create it in the first place. All you have at the
NRArena level is a (copy of) object's SPStyle - it's in the subclasses
of arena item (shape and glyphs), but to get from the href in the
filter property to the actual structure and values, you need some
additional interfaces. Hugo & Niko, did you give any thought to it?
Did you study how this is solved for gradients? Niko, did you check
out Hugo's initial SPFilter code? Please share your thoughts.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
8:18 a.m.
Niko,
One more thing. Is it possible to make the gaussian blur to use a
single pass for both horizontal and vertical blurring, and
correspondingly to use only one temp buffer instead of two? This
should make it noticeably faster and use less memory.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
12:36 p.m.
On 6/2/06, bulia byak <buliabyak@...400...> wrote:
Niko,
One more thing. Is it possible to make the gaussian blur to use a
single pass for both horizontal and vertical blurring, and
correspondingly to use only one temp buffer instead of two? This
should make it noticeably faster and use less memory.
Hmm, ignore this. I've read up on the topic of blurring and it seems
that the two-pass method you're using is actually faster :)
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
3:51 p.m.
On Fri, 2 Jun 2006 16:49:00 -0400
"bulia byak" <buliabyak@...400...> wrote:
Now that blurring works fine, I think next up is some
rearchitecturing
in your part. You are creating and deleting the filter object twice
per each call to nr_arena_item_render, once to get the extent from it
and then to do the actual render. This is inefficient. I think filter
object must be a property of NRArenaItem, created upon demand (i.e. on
first render) and then reused for all subsequent renders of that item.
Not only that is inefficient, but stops us from having any sensible way
to setting filter parameters. My original plan was, that NRArenaItem
would contain a pointer to filter it uses (or null pointer, if it
doesn't use filtering) Having the filter object created just before
rendering is merely a cheap imitation of that.
Similarly, gaussian blur filter should create its x and y kernels on
demand and not regenerate them upon each render.
Well, that's so-so. It might be a bit faster, but it would use quite a
bit more memory, while it is not rendering and complicate memory
management inside filters.
However, we need to update the filter if some of its parameters
change, and we need to get the list of filter primitives and their
parameters to create it in the first place. All you have at the
NRArena level is a (copy of) object's SPStyle - it's in the subclasses
of arena item (shape and glyphs), but to get from the href in the
filter property to the actual structure and values, you need some
additional interfaces. Hugo & Niko, did you give any thought to it?
Did you study how this is solved for gradients? Niko, did you check
out Hugo's initial SPFilter code? Please share your thoughts.
I've given that plenty of thought. Though didn't pass my mind, that
gradients do much the same, that we would need here. Have to take a
look there.
--
Niko Kiirala
niko@...1267...
http://niko.kiirala.com/
7:07 a.m.
I just committed a new blurring code which works much faster by using
subsampling and linear interpolation. Of course this is somewhat at
the expense of quality, but I think the quality is still acceptable,
yet now it renders with tolerable speed, even at high zooms, which
makes blur actually usable. (Check it out in the svg-filters branch!)
I think eventually we'll need to provide a user option to set the
level of subsampling to accommodate different hardware performance, as
well as to make sure it's turned off during bitmap export, for maximum
quality of the exported image.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
6205
days inactive
6209
days old
inkscape-devel@lists.inkscape.org
8 comments
4 participants
participants (4)
-
bulia byak -
Jon A. Cruz -
Loïc Martin -
Niko Kiirala