Hi Lukasz,
Lukasz Matuszczak wrote:
I'm interested in cache mechanisms implemented in Batik.
1. It would be nice to cache DOM tree somehow.
I figured out that the DocumentLoader uses some kind of uri cache, but
as far as I understand loadSVGDocument method in JSVGComponent, the new
DocumentLoader is used any time I use setURI method. Moreover the cache
is not shared among many JSVGCanvas instances.
This kind of cache could be really nice, but how could I use it when my
document is changing dynamically on SVGScreen. I have thought about
puting document in its begining state in cache, and then get it out of
cache cloning the DOM tree.
You should should be able to create your own instance of the
DocumentLoader class and fetch all of your 'base' documents from
it for all of your canvases. You should probably consider
extending the JSVGCanvas so you can provide the DocumentLoader
instance it should use (probably as a second argument to
setSVGDocument).
But would it be faster then parsing document from a file?
Yes cloning a DOM should be _much_ faster than reading.
Of course reading _and_ cloning will be slower than just reading...
One neat thing to do would be to have a DOM mutation event listener
on the root of the Document in the Cache (using capture not bubble)
then if a change is about to happen clone the tree and replace the
cache copy with the clone. This would avoid cloning everything
(as many 'reference' documents - fonts, symbols, are never touched).
2. Could you give me any hints how could I cache font definitions
available in svg files?
They already are. The FontFamilyResolver maps family names
to a GVTFontFamily, this is done globally for a JVM instance
(CSS gives you leeway to do this I believe - font family names
are supposed to be unique).
The font definitions are often the big part of my svg documents so I
would like to cache them (SVGGVTFont objects?), but I have no idea how
to integrate such kind of cache with batik.
You might instrument the code to make sure it is working as
expected.
Because, as far as I understand, the text rendering mechanism is the
slowest part of Batik it would be also great to create some kind of
simplified text tag, less powerful than original one but faster. Any
hints how to do it?
Well you can always create your own extension (in a custom
namespace of course). You will then need to create your own
GVT GraphicsNode. If you don't care about complex things creating
one built around 'drawString' should be fairly simple (although
bounds calcs might be a little tricky). There are some examples
of simple extensions in sources/org/apache/batik/extension/svg.
Ideally the current text stuff could detect if it was a 'simple'
text element or not and use the proper type of text node.
3. Would it be possible to serialize DOM or GVT tree somehow, or maybe
the whole JSVGCanvas and put it on the disk?
Well XML is the serial version of DOM ;)
More seriously currently Batik is not set up for this at all.
I don't know how much trouble this would be to add.
4. Is there any progress in implementing SVG 1.2 static css hint?
I haven't been working on it lately.
I have problems in splitting my documents in two parts dynamic
(transparent JSVGCanvas) and static, because:
a) The both parts should use the same definitions of gradients, fonts or
css styles. So how to do it effectively (memory usage is important)?
I would move those things into a third document that both reference.
b) To implement such layers I have to use two JSVGCanvas instances, so I
cannot use SVGScrollPane with them
Well you have the source to the SVGScrollPane so you might be
able to extend it to manage 'two' canvas's...
and I have two big image buffers.
Well the 'static' thing won't help this much as there will still be
a big image buffer for the 'static' part of the image.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
