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.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 >>>> >>>>
