--- Comment #30 from Alex Watson <alex_wat...@standardandpoors.com> 2009-04-09
02:08:31 PST ---
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
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.