Hi Henning, first of all, the image cache works with SoftReferences for images which are released by FOP. So if the JVM needs more memory the images are automatically removed. We've done extensive tests with this mechanism and it works very well. So I don't think that controlling the image cache helps anything in this case. BTW, there are two implementations of the ImageCache interface inside ImageFactory.java.
This is how exactly the cache works in the context of SVG graphics for PDF output: Generally, we can't reuse SVG graphics inside the same PDF, yet. If the same occurs multiple times in the same PDF it is rendered each time. In the case of SVG, the whole document is loaded at the time the FO tree is built (which is very early). That's not the case for many bitmap images. So the SVGs remain in memory during the whole layout phase until the end of the rendering run. In the case of certain bitmap images, the image can be released after rendering it to PDF since the image can be reused (the image is a separate object in PDF). Since the SVG has to be repainted each time, there cannot be an early release. So in the end, all SVGs remain in memory until the end of the rendering run. That applies to SVGs loaded through external-graphic. SVGs in instream-foreign-object should be released after the end of the page-sequence they're in. So, let's see what actually could help: - Without modification of FOP, you can only prefer instream-foreign-object over external-graphic and split up the document in multiple page-sequences if that's possible. That circumvents the image cache. - Implementing support for rendering SVGs as form XObjects in PDF would allow to release SVG referenced by external-graphic at the earliest possible point. Implementing that in a basic way should be fairly easy. There are however a few complicating features such as clickable links. - I've always considered an extension attribute on fo:external-graphic which serves as a hint for FOP if the image should be cached at all. But all images are going from FO tree to rendering stage via the image package's context map (which is held per rendering run). The hint would only allow skip putting the image in the image cache which really doesn't accomplish anything because the JVM can release its entries any time if they are not hard-referenced by a context map. So that doesn't really help I came to realize. - One possibility which I haven't investigated (it's just a foggy idea) is not to load an image at all if the size of the image is given through the external-graphic FO and the scaling is set to scale-to-fit. That would give us the option to load the image only at the rendering stage in which case the image would only be a very short-lived object. But I don't know if that would be possible in your case. You used "probably" in your post. Have you already run into any problems that you're bringing this up? If not, I'd just see what happens exactly. Anyway, if you want to do optimization in this area you have some options above but all but the first involves improving FOP. So far, FOP works pretty well for most use cases. HTH On 24.05.2007 01:17:49 Henning P. Schmiedehausen wrote: > Hi, > > I have an application that renders ~10 SVG graphics for a PDF > document. Each of these graphics is unique for a document and never > reused. So I know, that caching beyond the rendering of this single > document is of no use. > > My problem now is, that I have 70.000 - six digit figure documents to > render in each run. And I probably end up with 700.000 - 1.2 million > images in my image cache allocating lots of memory. > > Is there any way to control the image cache from the outside. Or > implement some sort of "least used expunge" that keeps it below a > certain size (I have a number of images that get renderered over and > over again so I appreciate some caching. I just want to get rid of the > SVGs. > > In the javadocs for 0.93 there is the o.a.fop.image.ImageCache > interface. However it seems not to be no implementation class of this > interface inside fop-0.93 , Is this just a dummy? > > Grateful for any pointers. Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
