[OpenJDK 2D-Dev] Rendering images from PDF files slower in OpenJDK
Phil Race
philip.race at oracle.com
Thu Oct 4 18:02:42 UTC 2018
On 10/03/2018 11:58 PM, Laurent Bourgès wrote:
> Hi,
> I will get the code and add debugging logs: env & system properties
> and java2d RenderingHints.
The code in pdfbox passes null for the hints. So there should be no
difference attributable to that.
-phil.
>
> 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
> <mailto: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 <mailto: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 <mailto: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 <mailto: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/6a933bb4/attachment.html>
More information about the 2d-dev
mailing list