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.