[OpenJDK 2D-Dev] Rendering images from PDF files slower in OpenJDK
Philip Race
philip.race at oracle.com
Fri Oct 5 06:06:02 UTC 2018
Yep .. I vaguely remembered that we had such a report but would also have
had to hunt to locate it.
So we have the probable reason but not the solution.
FWIW I think it would be a fun project for a LCMS developer ...
-phil.
On 10/4/18, 10:47 PM, Daniel Persson wrote:
> Hi Phil.
>
> Well it seems like you've been in this discussion before
>
> https://bugs.openjdk.java.net/browse/JDK-8041125
>
> Wasn't aware that PDFBox PDF2Image used the Kcms Provider per default.
> You may close this issue as we have figured out the reason.
>
> Best regards
> Daniel
>
> On Fri, Oct 5, 2018 at 7:27 AM Philip Race <philip.race at oracle.com
> <mailto:philip.race at oracle.com>> wrote:
>
>
>
> On 10/4/18, 10:22 PM, Daniel Persson wrote:
>> Hi Laurent
>>
>> Well that seems like a reasonable assumption.
>>
>> https://github.com/kalaspuffar/ColorConvTest/blob/master/KCMSTest.md
>>
>> The test with a "blank" image has a 1 seconds difference.
>>
>> And the test with an image from the PDF in question have a 52
>> seconds difference.
>
> I tried playing with different image data but I didn't see a
> sensitivity to that.
> Maybe I needed to try something more complex.
>>
>> So why don't OpenJDK 9 and forward have KcmsServiceProvider bundled?
>> Does this provider make a worse result on the image?
>>
> It is not open source. It cannot be part of OpenJDK. Ever.
> And see my other email for the other reasons.
> So there is no quick or easy solution.
>
> FWIW the #1 reason I left KCMS in Oracle 8 and even 9 was because
> of the MT performance
> issue, but as we now converge Oracle JDK & OpenJDK that was a
> non-starter and it was
> removed along with other closed source components.
>
> -phil.
>
>> Best regards
>> Daniel
>>
>>
>>
>>
>> On Fri, Oct 5, 2018 at 6:55 AM Laurent Bourgès
>> <bourges.laurent at gmail.com <mailto:bourges.laurent at gmail.com>> wrote:
>>
>> Phil,
>> I just gg a bit and got the PDFImage source:
>>
>> public static void main( String[] args ) throws IOException
>> 79 {
>> 80 try
>> 81 {
>> 82 // force KCMS (faster than LCMS) if available
>> 83
>> Class.forName("sun.java2d.cmm.kcms.KcmsServiceProvider");
>> 84 System.setProperty("sun.java2d.cmm",
>> "sun.java2d.cmm.kcms.KcmsServiceProvider");
>> 85 }
>> 86 catch (ClassNotFoundException e)
>> 87 {
>> 88 LOG.debug("KCMS service not found - using
>> LCMS", e);
>> 89 }
>> 90
>>
>> https://svn.apache.org/viewvc/pdfbox/trunk/tools/src/main/java/org/apache/pdfbox/tools/PDFToImage.java?revision=1829374&view=markup
>> <https://svn.apache.org/viewvc/pdfbox/trunk/tools/src/main/java/org/apache/pdfbox/tools/PDFToImage.java?revision=1829374&view=markup>
>>
>> That's all folks !
>>
>> Le ven. 5 oct. 2018 à 01:00, Philip Race
>> <philip.race at oracle.com <mailto:philip.race at oracle.com>> a
>> écrit :
>>
>> Yep. LCMS is the default in 8u.
>>
>> And although KCMS is a lot faster on my CConv test ...
>>
>> ~/jdk8u181/bin/java CConv
>> 13289
>>
>> ~/jdk8u181/bin/java
>> -Dsun.java2d.cmm=sun.java2d.cmm.kcms.KcmsServiceProvider
>> CConv
>> 5131
>>
>>
>> It makes no difference on the pdf conversion :
>>
>> ~/jdk8u181/bin/java -jar pdfbox-app-2.0.11.jar
>> PDFToImage -time test.pdf Rendered 1 page in 4985ms
>>
>> ~/jdk8u181/bin/java
>> -Dsun.java2d.cmm=sun.java2d.cmm.kcms.KcmsServiceProvider
>> -jar pdfbox-app-2.0.11.jar PDFToImage -time test.pdf
>> Rendered 1 page in 4723ms
>>
>>
>> Note: KCMS maybe faster on CConv but it has no support
>> for modern ICC profiles
>> and I haven't checked if it is even applying the pdfbox
>> one properly.
>> But it does have support to split a job into concurrent
>> tasks for sub-images
>> which can help on the larger images like the one I am
>> using in CConv.
>>
>> -phil.
>>
>> On 10/4/18, 2:24 PM, Philip Race wrote:
>>> I might be losing it, but I am 99% sure that LCMS is the
>>> color conversion engine in 8.
>>> KCMS was there only for backup. You'd have to know the
>>> magic flag to get it and
>>> no one has said anything to the effect that they are
>>> using it.
>>>
>>> -phil.
>>>
>>> On 10/4/18, 11:33 AM, Laurent Bourgès wrote:
>>>> Phil,
>>>> I wondered if ang RenderingHint defaults changed since 8...
>>>>
>>>> Moreover I started playing with linux perf + jit agent
>>>> and it is easy than before wigh oprofile + jvmtiagent.
>>>>
>>>> I noticed that OracleJDK8 uses KCMS and OpenJDK11 uses
>>>> LCMS for color conversion as does OpenJDK8, that could
>>>> explain the performance gap.
>>>>
>>>> Finally PDFImage test is run only once so the overhead
>>>> may come from warmup (jit, g1)...
>>>>
>>>> More later,
>>>> Laurent
>>>>
>>>> Le jeu. 4 oct. 2018 à 20:03, Phil Race
>>>> <philip.race at oracle.com
>>>> <mailto:philip.race at oracle.com>> a écrit :
>>>>
>>>>
>>>>
>>>> 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/c10b3f34/attachment-0001.html>
More information about the 2d-dev
mailing list