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
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