https://issues.apache.org/bugzilla/show_bug.cgi?id=46048
--- Comment #31 from Jeremias Maerki <jerem...@apache.org> 2009-04-09 12:05:37 PST --- Hi Alex (In reply to comment #30) > Hi Jeremias, > Thanks for the feedback. We currently render most of our PDF's twice - once > while discarding output to calculate the page count and then again with the Just to speed things up, you may want to render to the area tree XML (or to the new intermediate format with FOP Trunk) instead of to PDF if all you need is the page count. That should be faster and will not need to load all images on the first pass. > page count embedded within the document - I had expected the image cache to > get > more of a workout within a single session/run especially if logos are rendered > repeatedly on each page. > > However, I was not aware that the renderers were caching the images themselves > - can you point me to where in the code base that is happening? In http://svn.eu.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pdf/PDFRenderer.java?view=markup in putImage(): PDFXObject xobject = pdfDoc.getXObject(uri); if (xobject != null) { float w = (float) pos.getWidth() / 1000f; float h = (float) pos.getHeight() / 1000f; placeImage((float)pos.getX() / 1000f, (float)pos.getY() / 1000f, w, h, xobject); return; } It's not really "caching", but an image only needs to be embedded once in a PDF and can be reused multiple times. Not all output formats can do that, though. > My thinking is that the current image caching strategy works well for a mostly > static set of images - but is less flexible when the images are more dynamic > in > nature. I don't expect FOP to handle all of the various caching optimisations > that different people might want, but it might be a very small code change to > let people take care of it themselves. > > At the moment there is no way to alter the image cache behaviour (the objects > are private and there are no setters to substitute them) - assuming that I do > not want to modify the FOP code base in my system. > > I agree that only using the ImageManager as a cache for a single run would be > far less beneficial for performance, but it would allow people to implement > their own caching strategy via the UriResolver hooks. > > Even a simple code modification to disable (nullify) the cache on the > ImageManager, would allow people to implement their own image caching via the > UriResolver hooks. Ok, I see what you mean. I guess there are various level where this can happen. One would be on the level your suggest. HTTP, for example, allows to check file stamps. That could be used to trigger a reload of an image. But that is going to be difficult to implement with the URIResolver approach. In a high-volume system this might also result in too many round-trips for file stamp checking. How about just doing the same I've done with the expiration for the invalid URIs? We specify an expiration for the cached images. When the lease expires, the image is discarded and reloaded. That has very little management overhead, should address your use case and should be implementable with only a few lines of code now that we've already got the expiration code. Would that work for you? > Thanks again. > > btw - would you prefer me to raise this as a separate issue? No, I think it's fine to gather all informantion here, although it's maybe not the exact same case. BTW, I'd still be grateful for feedback on the URI "pre-resolution" idea in my patch. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
