>>>>> "MG" == Michael Gale <[EMAIL PROTECTED]> writes:
MG> Batik-User Group, The attached SVG file takes a really long time
MG> to render with Batik 1.5beta4b (60+ hours), and I was wondering if
MG> you could shed some light on to why it takes so long, and if you
MG> are planning on fixing the problem anytime soon. This could be
MG> caused by an infinite loop, but after debugging the problem for a
MG> while, it doesn't appear to be the case.
It is not an infinate loop it is simply N^2 rendering behaviour
triggered by your (fairly odd) use of BackgroundImage. If you
make the following change the document renders in under a minute:
<!-- <feComposite in2="SourceGraphic" operator="in" in="BackgroundImage"/> -->
<feComponentTransfer in2="SourceGraphic">
It is my belief that this gives identical results given that the
first thing you do is draw an opaque image in the background, so the
results of the in operation are just SourceGraphic.
MG> The problem appears to be caused by the filter effects within the
MG> file. If you delete those, the file renders in under five
MG> seconds. Almost every shape uses the defined filter effect, which
MG> is mostly composed of some alpha compositing and component-wise
MG> remapping functions. It seems that when the filter effects are
MG> applied it creates an inordinate number of temporary renderable
MG> surfaces and then composites them using a complex filter chain. I
MG> don't know enough about Batik's renderable surface classes to make
MG> an accurate assessment of what is going wrong, so I'm hoping this
MG> is where someone else could step in and take my place...
The root of the problem is the fairly weird definition of
BackgroundImage in SVG. Batik makes a tradeoff in size and speed
where it doesn't keep lots of temporary offscreen buffers and instead
recalculates the content on demand. In your particular case this
causes N squared behaviour in all the paths with the filter effect.
This could be fixed (without using significantly more memory) with
a much more sophisticated analysis of the rendering chains. This is
currently not planned work however.
I hope this at least sheds some light on the problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
