Thomas DeWeese wrote:
It is possible that we do not calculate the effected bounds of the change to the document when the filter effect is added (although in my testing this has worked). I'll try and take a look.
Well I hacked it down, and now my "short" example program is over 200 lines. I hope this won't be too painful for you. The program dynamically creates a document that looks like the following:
[...]
First, it displays an image from a .jpg file. Then it draws a white rectangle which partially obscures the image. Then the user can "erase" parts of this rectangle by drawing with the left mouse button, to reveal the image again. You'll see that the drawing doesn't seem to update properly. If you then click the right mouse button, the doc will get re-loaded, and the drawing thus becomes visible.
This won't work in Batik currently. When the size of the 'g' with the filter changes (because children are added) we don't currently rebuild the filter so it keeps it's old bounds.
Fortunately this example can be done about as simply by defining a pattern that uses the background content and setting the pattern as the fill for the lines. You need to setup the patternUnits and patternContent units properly but this should not be significantly more difficult than setting up feImage and the filter properly.
This is a general problem in Batik that 'indirect' references like this are generally not tracked dynamically. We did do some of this early on but discovered that it introduced huge memory leaks and backed it out. I think our infrastructure for tracking these sorts of things has improved to a point where we might be able to add it back but not before the 1.5.1 release (there are one or two remaining issues I want to try and fix before that release).
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
