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 That's all folks ! Le ven. 5 oct. 2018 à 01:00, Philip Race <philip.r...@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.r...@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.wo...@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.laur...@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.r...@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.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 >>>>>> >>>>>> >>