Hi,
Finally found the time to have another look at a possible image caching
solution.
I have a first working version of a generic image cacher. It turned out to
not be as simple as just extending the existing image handlers.
This is not really a proposal yet, more like a request for review/feedback.
I've posted some files at http://www.xs4all.nl/~paulpaul/batik/, for those
interested. Everything with "cache" in its title is my new stuff. Three
other files are slightly modified versions of existing ones. (mods tagged
with PAUL)
Also, for extra clarification I have newly generated a class diagram with
linked JavaDoc for the part of the svggen package I have been digging around
in. It's in SVG, so have a look at
http://www.xs4all.nl/~paulpaul/batik/doc/org/apache/batik/svggen/svggen.svg.
html
Note that this SVG file was generated using my caching code, so it may serve
as an example, too. There are only 4 different images in there, but they get
used about 50 times... By all means, open you source viewers, if you want.
Background:
Because image data is going to be stored only once, a transformation is
needed to make the image appear scaled correctly. Determining this
transformation is part of the image handler's job.
This means: extending the ImageHandler interface, creating a
CachedImageHandler, which specifies additional signatures for the
handleImage() method, all of them returning AffineTransforms. Also, because
an image can no longer always be specified by an <image> tag, a
createElement method is part of the extended interface.
The DefaultImageHandler class can implement these new functions: they do not
depend on the encoding. The new functions call handleTransform() and
handleHREF() to do encoding-specific work.
handleHREF() is implemented in the encoders. The existing ones,
ImageHandlerBase64Encoder,
ImageHandlerJPEGEncoder, and
ImageHandlerPNGEncoder
are extended with Cached.. equivalents, which are really very thin classes.
CachedImageHandlerBase64Encoder for instance, implements only handleHREF()
on a RenderedImage.
This handleHREF() is where the cache appears. The new ImageCacher class and
its subclasses, Embedded and External, has a lookup() method, which performs
all the nifty stuff expected of a cache. It is responsible for keeping track
of image data, adding e.g. an <image> tag to the <defs> section in the DOM
tree if the data has not been seen yet, and returning a unique id for the
image. Every image handler has its own ImageCacher instance.
The new CachedImageHandlers also imply new implementations for some
drawImage() APIs in SVGGraphics2D. As a first approach (to make all of this
appear a bit more harmless;) I have chosen to extend SVGGraphics2D in
CachedSVGGraphics2D, but I don't consider this an ideal solution. I have had
to modify SVGGraphics2D anyway, to get access to the DOMGroupManager.
It does offer the user the choice to cache their images, by:
1. Creating an instance of a CachedImageHandler implementation.
2. Giving it an ImageCacher instance.
3. Handing it to a SVGGeneratorContext.
4. Creating a CachedSVGGraphics2D with this context.
5. Giving the ImageCacher a reference to its DOMTreeManager or
topLevelGroup.
Note that I would like to get rid of steps 2 & 5.
In order for the ImageCacher to add <image> tags to a global <defs> section,
it needs a reference to the topLevelGroup handled by the DOMTreeManager of
the SVGGraphics2D instance this ImageCacher is attached to. The problem
there is: if I invoke the o so innocently named getTopLevelGroup() function,
it starts a new group!
I finally ended up hacking my own getTopLevelGroupNoRecycle(). Of course I
can overload the getTopLevelGroup() function, but is this the right way I
wonder?
In the sources I've put on the web, I have a working implementation for the
embedded image data case. No file-based caching yet, but it has been taken
into account. There is also the source of a small test application, called,
predictably, TestSVGGen. The function generateSVG() in there shows how to
drive CachedSVGGraphics2D.
Any comments, suggestions, advice, disapproving snorts? What have I
overlooked? Consequences for dynamic SVG? Granted, this may end up being
more of a reorganization than anyone cares for, with the 1.1 release coming
up...
Thanks,
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
