They really do that ? So we can't fix that in OpenJDK.
Options include
1) contribute a big and complex MT enhancement to LittleCMS.
2) Tweak PDFBox to be more MT itself.
3) Buy a faster computer :-)
4) Maybe (?) see if there is a way to sub-divide the work we hand to LCMS
but that is on the scale of (1) and is not something likely to happen unless
it is a community contribution.
But I must add the caveat that I am not sure how well KCMS actually did
what it was asked anyway .. very old ... and unmaintained .. no support for
modern ICC profiles .. and insecure (too trusting) .. and not open source.
So many reasons to ditch it. And maybe the performance came at the
cost of correctness ...
And again, I still didn't see the same degradation myself.
-phil.
On 10/4/18, 9:53 PM, Laurent Bourgès 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.r...@oracle.com
<mailto: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
<mailto: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 <mailto: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
<mailto: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
<mailto: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
<mailto: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
