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

[Laurent Bourgès]

Hi,
I will get the code and add debugging logs: env & system properties and
java2d RenderingHints.

I suspect these hints are different or have a noticiable impact: color
interpolation & rendering quality.

I suppose the backend corresponds to software loops but some 2d operations
can be accelerated ?

Anyway I will push any change in the code.

PS: I can run linux perf to profile both java & native code....

Cheers,
Laurent

Le jeu. 4 oct. 2018 à 07:50, Daniel Persson <mailto.woden at gmail.com> a
écrit :

> Hi Philip and Laurent.
>
> I've talked with Tilman and Andreas from the PDFBox team and they see
> similar connections to the ColorConvertOp filter but wanted to try with one
> of the images of the PDF as a raster.
>
> As we try different things I thought it good for collaboration to create a
> repository with the code so all can contribute.
>
> https://github.com/kalaspuffar/ColorConvTest
>
> I've run the 3 different tests on my Machine (Thinkpad P51s) with custom
> Gentoo installed, if important to the conversation.
>
> I tried to invite you all as collaborators to this repository if you think
> this is a bad Idea let me know.
>
> Best regards
> Daniel
>
> On Wed, Oct 3, 2018 at 7:51 PM Laurent Bourgès <bourges.laurent at gmail.com>
> wrote:
>
>> 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/20181004/de7467f5/attachment.html>