为什么PDFBox PDFRenderer速度很慢？

Question

我想转换一个PDFBox格式文件到一个使用TIFF2.x和PDFRenderer类。

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

下面是我的示例代码

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");

因为我运行的是Java8(准确地说是1.8.0_161)，但这并没有什么区别。

感谢你的每一个想法，致以敬意

托马斯

Answer 1

将升级到JDK 1.8.0_191，于2018年10月或JDK 9.0.4发布。

从Pdfbox docs，

PDFBox和Java 8

在1.8.0_191之前的Java 8或9.0.4之前的Java 9中使用PDFBox时的重要注意事项

由于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值成二次比例关系。第一个图像的速度较慢可能是一些初始化开销。(但目前这一切都是胡乱猜测。)