为什么PDFBox PDFRenderer很慢

Question

我想使用 PDFBox 2.x 和 PDFRenderer Class 将 PDF 转换为 TIFF。

但与代笔相比，它的运行速度非常慢。

这是我的示例代码

public class SpeedTest
{
    static long startTime = System.currentTimeMillis ();
    public static void logTime (String msg)
    {
        long now = System.currentTimeMillis ();
        System.out.println (String.format ("%.3f: %s", (now - startTime) / 1000.0, msg));
        startTime = now;
    }
    public static void main (String[] args) throws Exception
    {
        //System.setProperty ("sun.java2d.cmm", "sun.java2d.cmm.kcms.KcmsServiceProvider");
        String pdfFileName = args[0];
        String tiffFileName = args[1];
        PDDocument document = PDDocument.load (new File (pdfFileName));
        logTime (pdfFileName + " loaded.");
        PDFRenderer pdfRenderer = new PDFRenderer (document);
        logTime ("intitalized renderer.");
        BufferedImage img = pdfRenderer.renderImageWithDPI (0, 600, ImageType.RGB);
        logTime ("page rendered as image.");
        ImageIO.write (img, "TIFF", new File (tiffFileName));
        logTime ("image saved as TIFF.");
    }
}

输出如下

0.521: sample.pdf loaded.
0.013: intitalized renderer.
2.910: page rendered as image.
2.005: image saved as TIFF.

如您所见，调用pdfRenderer.renderImageWithDPI需要近 3 秒(ImageIO.write -call 也需要 2 秒(。

当使用ghostscript完成相同的操作时，完成的任务在0.4秒内完成。

time gs -dQUIET -dBATCH -dNOPAUSE -sstdout=/dev/null -sDEVICE=tifflzw -r600 -dFirstPage=1 -dLastPage=1 -sOutputFile=sample.tif sample.pdf
real    0m0.389s
user    0m0.340s
sys     0m0.048s

我也已经尝试过

System.setProperty("sun.java2d.cmm", "sun.java2d.cmm.kcms.KcmsServiceProvider");

因为我运行的是 Java 8(准确地说是 1.8.0_161(，但这没有区别。

感谢每一个想法，问候

托马斯

Answer 1

升级到 2018 年 10 月发布的 JDK 1.8.0_191 或 JDK 9.0.4。

来自 Pdfbox 文档，

PDFBox 和 Java 8

将 PDFBox 与 Java 8 一起使用时的重要通知低于 1.8.0_191 或 Java 9 9.0.4 之前

版本

由于java颜色管理模块向"LittleCMS"，用户可能会体验到颜色性能缓慢操作。一种解决方案是禁用LittleCMS以支持旧的KCMS(柯达色彩管理系统(由：

从-Dsun.java2d.cmm=sun.java2d.cmm.kcms.KcmsServiceProvider开始或呼叫

System.setProperty("sun.java2d.cmm", "sun.java2d.cmm.kcms.KcmsServiceProvider")

来源：

https://bugs.openjdk.java.net/browse/JDK-8041125

Answer 2

根据我的实验，这种缓慢只发生在文档的第一个渲染页面。如果呈现多页文档的所有页面，则第一个页面之后的所有页面的渲染速度更快。渲染的绝对速度也在很大程度上取决于所用 DPI 的大小。

Render 6 document pages at 600 DPI
4.903s: page 0 rendered as image.
4.205s: page 1 rendered as image.
3.946s: page 2 rendered as image.
3.866s: page 3 rendered as image.
3.761s: page 4 rendered as image.
3.633s: page 5 rendered as image.
Render 6 document pages at 300 DPI
3.241s: page 0 rendered as image.
1.308s: page 1 rendered as image.
1.155s: page 2 rendered as image.
1.156s: page 3 rendered as image.
1.109s: page 4 rendered as image.
1.083s: page 5 rendered as image.
Render 6 document pages at 150 DPI
2.507s: page 0 rendered as image.
0.555s: page 1 rendered as image.
0.386s: page 2 rendered as image.
0.373s: page 3 rendered as image.
0.410s: page 4 rendered as image.
0.361s: page 5 rendered as image.
Render 6 document pages at 72 DPI
2.455s: page 0 rendered as image.
0.333s: page 1 rendered as image.
0.213s: page 2 rendered as image.
0.190s: page 3 rendered as image.
0.175s: page 4 rendered as image.
0.171s: page 5 rendered as image.

我认为这里的问题是AWT图形在软件中进行所有渲染，并且在恒定的像素填充率下，渲染时间与DPI值呈二次缩放。第一个图像的缓慢可能是一些初始化开销。(但目前这都是一个疯狂的猜测。