George Armhold wrote:
Thomas DeWeese wrote:
Another alternative which I haven't tried yet is to simply replace the whole JSVGComponent in the frame with one that already has the doc loaded. But that seems like overkill. Any other ideas for a speedup?
This is exactly what I would do. I'm not sure why you consider this overkill.
It just seems that replacing a Swing component ought to have more overhead than updating the graphics of an already added component. Of course "updating the graphics" of a complex batik doc is no simple thing, so perhaps this is the right thing to do. I'll give it a try and report back.
The overhead of replacing the swing component is likely very small compared with the overhead of drawing a document that takes a second or two to build.
This would be the text. We've spend a lot of time on it but text is still 10x slower than I would like to see it.
Do you really expect to see an order of magnitude improvement in text speed some day? Your answer will probably be over my head, but what's involved?
I don't know if I would say that I expect to see the improvement, but it is pretty definitely possible. Right now the major bottleneck seems to be the core JDK classes, in particular the AttributedString class is incredibly slow (partly because we attach so many properties to the string).
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
