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
