Hi Sergey,
Le lun. 8 mars 2021 à 06:00, Sergey Bylokhov a
écrit :
> Hi, Laurent.
>
> On 04.10.2018 23:45, Laurent Bourgès wrote:
> > I looks like a call to let me have a look. Maybe I could inspect what
> makes LCMS slow (lerp?) ... and optimize the C code or at least tune gcc
> options.
>
>
Hi, Laurent.
On 04.10.2018 23:45, Laurent Bourgès wrote:
I looks like a call to let me have a look. Maybe I could inspect what makes
LCMS slow (lerp?) ... and optimize the C code or at least tune gcc options.
Did you have a chance to look at it? =)
I would not make MT in lcms as it can
Phil,
Le ven. 5 oct. 2018 à 08:06, Philip Race a écrit :
> 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 ...
>
I
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
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
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
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
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.
So why don't OpenJDK 9 and
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
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
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
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
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
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 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
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.
As jpeg decoder in openjdk11 is different than oraclejdk8, it may cause
more ColorConvertOp filter operations ... if color profiles are different.
Anyway this performance is
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
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
>
Hi,
FYI I will run profilers on this test case to compare Oracle JDK8 vs
OpenJDK11...
Will then give you my analysis.
Cheers,
Laurent
Le mer. 26 sept. 2018 à 23:51, Philip Race a
écrit :
> Interesting and I assume that it was somewhat less in JD8u ?
> Off the top of my head that is one thing
Interesting and I assume that it was somewhat less in JD8u ?
Off the top of my head that is one thing that didn't change in any big
way since JDK 8u.
Perhaps something has changed so that it is now [considered] needed
whereas before
it was not? So did it go from zero percent to 29% or from
Hi Phil
What the PDFBox team told me it could have something to do with color
mapping.
And my quick profiling shows that the code spends 29% of the time inside of
java.awt.image.ColorConvertOp.filter on java 11
But I'll open a issue.
Best regards
Daniel
On Wed, Sep 26, 2018, 19:33 Phil Race
Multiple pieces are changing across these releases.
Is it the JPEG writing ? Is it freetype vs t2k (font performance)
is it harfbuzz vs icu (text layout), is it marlin vs ductus
(rasterization) ?
So it is very hard to say with any certainty what the cause of the
difference is .. or
why 10
21 matches
Mail list logo
