> -----Original Message----- > From: Michael Reiche [mailto:[EMAIL PROTECTED] > > I use an embedded version of FOP, primarly to keep the Java "hot" > getting benefit from JIT. PCL-output is top priority rather than PDF. > But I face the problem that the PCL-renderer is rather slow compared to > the PDF-renderer (which my initital testing was based on ). > > I feed FOP with an XSL-FO document, which in this test generates 7 pages > (source is 176464 bytes). The document contains in-stream SVG-graphics, > which the PCL-renderer completly ignores - thats another challenge. Its'
Well, the FOP Output Targets page (http://xml.apache.org/fop/output.html) does indicate that SVG support for the PCL Renderer is somewhat limited. This shows itself in the source, I guess, where the PDFRenderer contains import statements for the Batik bridges as well as a reference to the java.awt.geom lib (as opposed to the PCLRenderer). If you really want to have a go at extending the PCLRenderer to offer the same support as the PDFRenderer, I think this is your starting-point. Explanation for this probably lies in the fact that Batik offers direct SVG2PDF conversion via its Rasterizer (which in turn uses FOP's PDFTranscoder), so every once in a while, members of the Batik dev-team or Batik users happily provide FOP with a few patches to enhance the SVG support when rendering to PDF. > running in Java1.4.2 on Linux in a headless environment. > > Timing of the 6 first runs of the same document, each sequence starting > from a new "cold" Java VM, is like this: > <snip/> > > Notice that the PDF-renderer just needs 1 run to benefit from JIT, but > the PCL-renderer neverer improves performance. It should be noted that > the server running the Java VM is doing nothing besides my tests. > I'm not too well-informed about the particulars of JIT, but the PDFRenderer *is* the most advanced Renderer offered by FOP. Maybe a redesign of the PCLRenderer modeled according to the current PDFRenderer could improve performance in this way. ( I, for one, would be *very* curious to see how the Batik team would respond to a full-fledged PCLTranscoder ). Currently the PCLRenderer consists solely of a PCLRenderer and a PCLStream, whereas the PDFRenderer has a whole lib (org.apache.fop.pdf) at its disposal, allowing for a more controlled and detailed optimization. > A note regarding the PCL-rendering: starting with the 2. run the first 3 > or 4 pages renders quickly, but then a complete slowdown occurs. This > could indicate massive garbage collection or.....? > Could be... Have you tried changing the size of the JVM heap? If that has an impact, this would indeed be what is happening over here. > I've had my eyes on both PDFRenderer.java and PCLRenderer.java, but I > haven't been able to spot that magic difference. Could it be that the > PDF-renderer has suffered from the same performance-problem, and someone > remembers how it was improved, or otherwise has some tips to improve the > PCL-renderer? Browsed through the fop-dev list searching for this, but haven't yet found traces of previous discussions about this. I have noticed that the PCLRenderer was donated to FOP, whereas the PDFRenderer was there from the very start. My guess would be that, initially it was more of a convenience-addition, allowing to skip the intermediate generation of a (physical) PDF and send the output directly to the PCL printer ( same goes for the PS Renderer ). Suggestion would be to study the PDF rendering process very closely, and try to 'mimic' it in terms of PCL, maybe this gets you on track ...? And of course, when you *do* decide to make changes like this, and they turn out to work properly and improve performance, don't forget to let us know about this :) Hope these help! Greetz, Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]