https://issues.apache.org/bugzilla/show_bug.cgi?id=46048
--- Comment #30 from Alex Watson <alex_wat...@standardandpoors.com> 2009-04-09 02:08:31 PST --- 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 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? 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. Thanks again. btw - would you prefer me to raise this as a separate issue? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
