On 10/3/18, 1:15 AM, Laurent Bourgès wrote:
Phil,

If you look at the given pdf file, it has large images that exceed 2k so such ones may be more costly to convert.

FWIW the one I profiled was by far the largest at 2577x1540.
The rest are more like 100x100, 200x200 or 500x500 - all approximations.

As jpeg decoder in openjdk11 is different than oraclejdk8, it may cause more ColorConvertOp filter operations ... if color profiles are different.

That doesn't seem likely and in fact since I  instrumented ColorConvertOp in 8 & 11,  I know exactly how many times it was invoked by pdfbox, (11 times in both cases) and that all the image data is the same. SRC and DEST are the same types etc.

Also the version of LCMS is the same in 8 and 11 (v2.9).

-phil

Anyway this performance is not related to Marlin renderer, so I can not help much except in its diagnostic.

Cheers,
Laurent

Le mar. 2 oct. 2018 à 23:35, Philip Race <philip.r...@oracle.com <mailto:philip.r...@oracle.com>> a écrit :

    I've spent some time examining what pdfbox is passing to
    ColorConvertOp
    It is called about 10 or 11 times in this test with images
    typically 1-2K in each dimension.
    The input image is a Custom BufferedImage which uses an
    ICC_ColorSpace constructed
    from a color profile file that is embedded in pdfbox which is an
    open source equivalent
    of what Acrobat uses. It has a 4 component raster and is opaque

    This is filtered into a 3 component standard INT_RGB ColorModel.

    I've distilled this down into a small program which has an copy of
    the method
    that is defined in pdfbox and is invoking the supposedly slow
    ColorConvertOp.

    So I believe this is all exactly what is happening in pdfbox.

    What I find is that it is actually much faster on JDK11 than JDK 8.

    prrubuntu:~$ ~/jdk-11/bin/java CConv
    4881
    prrubuntu:~$ ~/jdk8u181/bin/java CConv
    12529


    I can't say why that would be but the results are clear.
    So I am left to suppose that pdfbox really is doing something
    different in 8 vs 11.
    Or that this not the real problem. What do others see ?

    I've attached the program. The 1Mb color profile file can be got
    from the pdfbox sources.

    -phil.


    On 10/2/18, 9:35 AM, Laurent Bourgès wrote:
    Hi Daniel,


        Let's not compare apples and oranges. What I can see it takes
        the same route and behave similarly.


     I agree, I did not take enough time to get accurate profiles, sorry.


        If you look at
        http://uhash.com/java_reg/Call_Tree_java_8.html
        http://uhash.com/java_reg/Call_Tree_java_11.html

        You can see that ConvertOp.filter takes 1.5s longer on Java 11.


    I confirm: 1.8s vs 300ms.

    Philip, do you know what could have change in this 2d area ?

    I imagine ColorConvertOp delegates to native code so color
    profile (ICC) or hidpi support may have an impact here (or just
    compiler options may be different) ...

    If needed, I could profile native code using oprofile / perf.

    Laurent

Reply via email to