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.
