Paul,
I will give your feedback later after I get a chance to look into the
work you have done. It looks really good and the diagram is very
impressive and a good example of what you have done.
Thanks,
Vincent.
"Evenblij, Paul" wrote:
>
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
