[OpenJDK 2D-Dev] Rendering images from PDF files slower in OpenJDK

[Laurent Bourgès]

Very good job, phil.

I will try your CCONV test on my linux machine to see if it is platform
dependent ... or hw ?

Laurent

Le mer. 3 oct. 2018 à 19:19, Philip Race <philip.race at oracle.com> a écrit :

>
>
> 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.race at 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181003/faaf7c3f/attachment-0001.html>