From amaembo at gmail.com  Mon Oct  1 03:29:39 2018
From: amaembo at gmail.com (Tagir Valeev)
Date: Mon, 1 Oct 2018 10:29:39 +0700
Subject: [OpenJDK 2D-Dev] RFR JDK-8211300: Convert C-style array
	declarations in Java code
Message-ID: <CAE+3fjZo1t6fGpSZiK09Sf1se6f8uPwmfda3A9qyVr89BkDdgg@mail.gmail.com>

Hello!

Please review JDK-8211300 [1] this change: [2]. Also it needs a
sponsor as I have only JDK author status in OpenJDK Census [3].

The discussion in core-libs-dev [4] shows that it's desired to get rid
of old style array declarations like `int array[]` and massively
convert them to `int[] array`. I volunteered to work on this. As Alan
Bateman noted [5], java.desktop module is pushed to separate repo, so
it would be better to process it separately, thus I'd like to start
with it.

The changeset was created in the following steps:
* Import JDK sources to IntelliJ IDEA
* Mark java.desktop/aix/classes, java.desktop/macosx/classes,
java.desktop/unix/classes, java.desktop/solaris/classes,
java.desktop/windows/classes and java.desktop/share/classes as source
roots
* Disable automatic formatting on the whole project
* Run the inspection "C-style array declaration"
* Apply the quick-fix massively
* Perform regex replace over changed files only:
Search: Copyright \(c\) (\d+), (\d+), Oracle and/or its affiliates.
All rights reserved.
Replace: Copyright \(c\) $1, 2018, Oracle and/or its affiliates. All
rights reserved.
* Perform regex replace over changed files only:
Search: Copyright \(c\) (\d+), Oracle and/or its affiliates. All
rights reserved.
Replace: Copyright \(c\) $1, 2018, Oracle and/or its affiliates. All
rights reserved.
* It appeared that compound declarations like `byte r[], g[], b[];`
are converted to `byte[] r;byte[] g; byte[] b;` which does not look
nice while compilable. I found three such cases via simple regexp
search in BMPImageReader#658, BMPImageWriter#325 and
AreaAveragingScaleFilter#66 and fixed them manually.

In total 339 files were changed with 1335 lines of array declaration
updates and 310 lines of copyright updates. I reviewed the generated
patch by eyes, but only partially, because it's too big. Also I
performed some kind of simple sanity check using regexps:

$ grep '^+[^+]' jdk.patch | grep -v 'Oracle and/or its affiliates. All
rights reserved'|grep -v '\[\]'|wc
      0       0       0
(check that every updated line contains either copyright message or [])

With best regards,
Tagir Valeev.

[1] https://bugs.openjdk.java.net/browse/JDK-8211300
[2] http://cr.openjdk.java.net/~tvaleev/webrev/8211300/r1/
[3] http://openjdk.java.net/census#tvaleev
[4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055390.html
[5] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055759.html

From philip.race at oracle.com  Mon Oct  1 16:19:39 2018
From: philip.race at oracle.com (Philip Race)
Date: Mon, 01 Oct 2018 09:19:39 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> [12]RFR: [JDK-8074824]: Resolve
 disabled warnings for libawt_xawt
In-Reply-To: <57768c04-a994-46f8-8322-fa89058d58c9@default>
References: <57768c04-a994-46f8-8322-fa89058d58c9@default>
Message-ID: <5BB2491B.7000501@oracle.com>

Hi,

1) Has this been built on all platforms ?
2)  I can't find the list of warnings that you are seeing and fixing and 
they are all over the place.
So adding 2d-dev and build-dev.
For each of these changes, please show what was the warning that you 
received from the compiler
This might sound like a lot of work, but it won't be disproportionate 
and I've made the same
request for similar reviews and without it, it is hard to review the 
changes.

For example (and I do mean just example)
http://cr.openjdk.java.net/~kaddepalli/8074824/webrev01/src/java.desktop/unix/native/common/awt/awt_Font.c.udiff.html

why would that not be #ifdef instead ?

3) Testing .. did you run at least all our jtreg tests to make sure you 
didn't break
some behaviour ..

-phil.

On 9/29/18, 8:18 PM, Krishna Addepalli wrote:
>
> Hi All,
>
> Please review a fix for JDK-8074824: 
> https://bugs.openjdk.java.net/browse/JDK-8074824
>
> Webrev: http://cr.openjdk.java.net/~kaddepalli/8074824/webrev01/ 
> <http://cr.openjdk.java.net/%7Ekaddepalli/8074824/webrev01/>
>
> Most of the warnings have been fixed for Linux, Mac and Windows.
>
> Thanks,
>
> Krishna
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181001/3465dd6a/attachment.html>

From philip.race at oracle.com  Mon Oct  1 16:38:06 2018
From: philip.race at oracle.com (Philip Race)
Date: Mon, 01 Oct 2018 09:38:06 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> [12]RFR: [JDK-8074824]: Resolve
 disabled warnings for libawt_xawt
In-Reply-To: <5BB2491B.7000501@oracle.com>
References: <57768c04-a994-46f8-8322-fa89058d58c9@default>
 <5BB2491B.7000501@oracle.com>
Message-ID: <5BB24D6E.5020600@oracle.com>

You really do need to explain *each* of the changes better.
This one .. why not NULL ?
http://cr.openjdk.java.net/~kaddepalli/8074824/webrev01/src/java.desktop/share/native/libawt/java2d/loops/ProcessPath.c.udiff.html

-phil

On 10/1/18, 9:19 AM, Philip Race wrote:
> Hi,
>
> 1) Has this been built on all platforms ?
> 2)  I can't find the list of warnings that you are seeing and fixing 
> and they are all over the place.
> So adding 2d-dev and build-dev.
> For each of these changes, please show what was the warning that you 
> received from the compiler
> This might sound like a lot of work, but it won't be disproportionate 
> and I've made the same
> request for similar reviews and without it, it is hard to review the 
> changes.
>
> For example (and I do mean just example)
> http://cr.openjdk.java.net/~kaddepalli/8074824/webrev01/src/java.desktop/unix/native/common/awt/awt_Font.c.udiff.html
>
> why would that not be #ifdef instead ?
>
> 3) Testing .. did you run at least all our jtreg tests to make sure 
> you didn't break
> some behaviour ..
>
> -phil.
>
> On 9/29/18, 8:18 PM, Krishna Addepalli wrote:
>>
>> Hi All,
>>
>> Please review a fix for JDK-8074824: 
>> https://bugs.openjdk.java.net/browse/JDK-8074824
>>
>> Webrev: http://cr.openjdk.java.net/~kaddepalli/8074824/webrev01/ 
>> <http://cr.openjdk.java.net/%7Ekaddepalli/8074824/webrev01/>
>>
>> Most of the warnings have been fixed for Linux, Mac and Windows.
>>
>> Thanks,
>>
>> Krishna
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181001/5a54364a/attachment.html>

From philip.race at oracle.com  Mon Oct  1 16:44:55 2018
From: philip.race at oracle.com (Philip Race)
Date: Mon, 01 Oct 2018 09:44:55 -0700
Subject: [OpenJDK 2D-Dev] RFR JDK-8211300: Convert C-style array
 declarations in Java code
In-Reply-To: <CAE+3fjZo1t6fGpSZiK09Sf1se6f8uPwmfda3A9qyVr89BkDdgg@mail.gmail.com>
References: <CAE+3fjZo1t6fGpSZiK09Sf1se6f8uPwmfda3A9qyVr89BkDdgg@mail.gmail.com>
Message-ID: <5BB24F07.1010806@oracle.com>

Hi,

On 9/30/18, 8:29 PM, Tagir Valeev wrote:
> Hello!
>
> Please review JDK-8211300 [1] this change: [2]. Also it needs a
> sponsor as I have only JDK author status in OpenJDK Census [3].

Adding awt + swing.
I can sponsor this. Have you submitted a build via 
hg.openjdk.java.net/jdk/submit ?
I can submit a job if you have not.
I have also made a few updates to the bug report.

-phil.
>
> The discussion in core-libs-dev [4] shows that it's desired to get rid
> of old style array declarations like `int array[]` and massively
> convert them to `int[] array`. I volunteered to work on this. As Alan
> Bateman noted [5], java.desktop module is pushed to separate repo, so
> it would be better to process it separately, thus I'd like to start
> with it.
>
> The changeset was created in the following steps:
> * Import JDK sources to IntelliJ IDEA
> * Mark java.desktop/aix/classes, java.desktop/macosx/classes,
> java.desktop/unix/classes, java.desktop/solaris/classes,
> java.desktop/windows/classes and java.desktop/share/classes as source
> roots
> * Disable automatic formatting on the whole project
> * Run the inspection "C-style array declaration"
> * Apply the quick-fix massively
> * Perform regex replace over changed files only:
> Search: Copyright \(c\) (\d+), (\d+), Oracle and/or its affiliates.
> All rights reserved.
> Replace: Copyright \(c\) $1, 2018, Oracle and/or its affiliates. All
> rights reserved.
> * Perform regex replace over changed files only:
> Search: Copyright \(c\) (\d+), Oracle and/or its affiliates. All
> rights reserved.
> Replace: Copyright \(c\) $1, 2018, Oracle and/or its affiliates. All
> rights reserved.
> * It appeared that compound declarations like `byte r[], g[], b[];`
> are converted to `byte[] r;byte[] g; byte[] b;` which does not look
> nice while compilable. I found three such cases via simple regexp
> search in BMPImageReader#658, BMPImageWriter#325 and
> AreaAveragingScaleFilter#66 and fixed them manually.
>
> In total 339 files were changed with 1335 lines of array declaration
> updates and 310 lines of copyright updates. I reviewed the generated
> patch by eyes, but only partially, because it's too big. Also I
> performed some kind of simple sanity check using regexps:
>
> $ grep '^+[^+]' jdk.patch | grep -v 'Oracle and/or its affiliates. All
> rights reserved'|grep -v '\[\]'|wc
>        0       0       0
> (check that every updated line contains either copyright message or [])
>
> With best regards,
> Tagir Valeev.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8211300
> [2] http://cr.openjdk.java.net/~tvaleev/webrev/8211300/r1/
> [3] http://openjdk.java.net/census#tvaleev
> [4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055390.html
> [5] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055759.html

From bourges.laurent at gmail.com  Mon Oct  1 17:52:36 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Mon, 1 Oct 2018 19:52:36 +0200
Subject: [OpenJDK 2D-Dev] Rendering images from PDF files slower in
	OpenJDK
In-Reply-To: <CAKjRUT7jb7tqAEpmkFbCrg=Vn29Q3NfcKZ5zm0JsFS0R59UocQ@mail.gmail.com>
References: <CALLYd6TyN2Fc+vFOrg9e-RA+M67G56gJ8E1jn+1CnFYkz6cKZg@mail.gmail.com>
 <3584070c-9406-b7a2-2d68-b485a0c1fcdd@oracle.com>
 <CALLYd6SC2+uEm4kVCZ1cLVm9EiKVnejcU+PwcmzZ0inPYRH3EQ@mail.gmail.com>
 <5BABCDDD.5080403@oracle.com>
 <CAKjRUT7jb7tqAEpmkFbCrg=Vn29Q3NfcKZ5zm0JsFS0R59UocQ@mail.gmail.com>
Message-ID: <CAKjRUT6qt1MkYcs+-3zE+yv0jrnRVt4_Fjcj=n=D+zZDgsiUKg@mail.gmail.com>

Hi,
I quickly run your test with Oracle JDK8 and OpenJDK 11:
Here are the CPU profiles:
http://cr.openjdk.java.net/~lbourges/pdfbox_profiles/

On JDK8:
java version "1.8.0_192-ea"
Java(TM) SE Runtime Environment (build 1.8.0_192-ea-b04)
Java HotSpot(TM) 64-Bit Server VM (build 25.192-b04, mixed mode)
Rendered 1 page in 3375ms

 777 ms org.apache.pdfbox.pdmodel.graphics.image.SampledImageReader.
getRGBImage
  17.8% - 766 ms
org.apache.pdfbox.pdmodel.graphics.image.SampledImageReader.from8bit
  12.6% - 541 ms
org.apache.pdfbox.pdmodel.graphics.image.PDImageXObject.createInputStream
  12.6% - 541 ms org.apache.pdfbox.pdmodel.common.PDStream.createInputStream

On JDK11:

openjdk version "11" 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11+28)
OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)
Rendered 1 page in 4789ms

2,059 ms org.apache.pdfbox.pdmodel.graphics.image.SampledImageReader.
getRGBImage
  36.0% - 2,054 ms
org.apache.pdfbox.pdmodel.graphics.image.SampledImageReader.from8bit
  26.2% - 1,495 ms
org.apache.pdfbox.pdmodel.graphics.color.PDDeviceCMYK.toRGBImage
  26.2% - 1,495 ms
org.apache.pdfbox.pdmodel.graphics.color.PDDeviceCMYK.toRGBImageAWT
  26.2% - 1,495 ms
org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.toRGBImageAWT
  26.0% - 1,481 ms java.awt.image.ColorConvertOp.filter

Actually, pdfbox's SampledImageReader.from8bit() do not use the same
path between JDK8 and JDK11... and ColorConvertOp costs 25% (in my
case)

Cheers,
Laurent

Le jeu. 27 sept. 2018 ? 09:19, Laurent Bourg?s <bourges.laurent at gmail.com>
a ?crit :

> 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 <philip.race at oracle.com> a
> ?crit :
>
>> 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 10% to 29% ?
>>
>> But even that doesn't on it own account for everything.
>> 29% of 8 seconds would be about 2.5 seconds and doesn't explain going from
>> < 3 seconds to 8 seconds .. we are still missing at least 2.5 seconds ..
>>
>>
>> -phil.
>>
>> On 9/26/18, 11:08 AM, Daniel Persson wrote:
>>
>> 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 <philip.race at oracle.com> wrote:
>>
>>> 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 got so much better than 9  .. even if still not back to JDK 8.
>>>
>>> Please file a bug at java.com.
>>>
>>> -phil.
>>>
>>> On 09/25/2018 10:42 PM, Daniel Persson wrote:
>>> > Hi everyone,
>>> >
>>> > We render a lot of images with PDFBox with Java 1.8.0 and we want to
>>> > upgrade to the current OpenJDK 11 but sadly we see some performance
>>> > degradation switching over to OpenJDK. Anyone have a suggestion to
>>> > remedy this issue, or can explain why it is slower?
>>> >
>>> > Using the PDFBox app current release downloadable from
>>> > http://www-us.apache.org/dist/pdfbox/2.0.11/pdfbox-app-2.0.11.jar
>>> >
>>> > Running the command
>>> > java -jar pdfbox-app-2.0.11.jar PDFToImage -time test.pdf
>>> >
>>> > We see the following result
>>> >
>>> > ---------------------------------------------------------
>>> > java version "1.8.0_181"
>>> > Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
>>> > Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
>>> > Rendered 1 page in 2762ms
>>> > ---------------------------------------------------------
>>> > openjdk version "9.0.4"
>>> > OpenJDK Runtime Environment (build 9.0.4+11)
>>> > OpenJDK 64-Bit Server VM (build 9.0.4+11, mixed mode)
>>> > Rendered 1 page in 8034ms
>>> > ---------------------------------------------------------
>>> > openjdk version "10.0.2" 2018-07-17
>>> > OpenJDK Runtime Environment 18.3 (build 10.0.2+13)
>>> > OpenJDK 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode)
>>> > Rendered 1 page in 4255ms
>>> > ---------------------------------------------------------
>>> > openjdk version "11" 2018-09-25
>>> > OpenJDK Runtime Environment 18.9 (build 11+28)
>>> > OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)
>>> > Rendered 1 page in 4275ms
>>> > ---------------------------------------------------------
>>> > openjdk version "12-ea" 2019-03-19
>>> > OpenJDK Runtime Environment 19.3 (build 12-ea+11)
>>> > OpenJDK 64-Bit Server VM 19.3 (build 12-ea+11, mixed mode)
>>> > Rendered 1 page in 4399ms
>>> >
>>> > The pdf file used in this example can be downloaded from
>>> >
>>> https://drive.google.com/file/d/139wP6PDmmQ6KBTyeJTETIrplSuOUgFfG/view?usp=sharing
>>> >
>>> > Best regards
>>> > Daniel
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181001/f0f95fa7/attachment-0001.html>

From philip.race at oracle.com  Mon Oct  1 21:10:27 2018
From: philip.race at oracle.com (Phil Race)
Date: Mon, 1 Oct 2018 14:10:27 -0700
Subject: [OpenJDK 2D-Dev] Rendering images from PDF files slower in
 OpenJDK
In-Reply-To: <CAKjRUT6qt1MkYcs+-3zE+yv0jrnRVt4_Fjcj=n=D+zZDgsiUKg@mail.gmail.com>
References: <CALLYd6TyN2Fc+vFOrg9e-RA+M67G56gJ8E1jn+1CnFYkz6cKZg@mail.gmail.com>
 <3584070c-9406-b7a2-2d68-b485a0c1fcdd@oracle.com>
 <CALLYd6SC2+uEm4kVCZ1cLVm9EiKVnejcU+PwcmzZ0inPYRH3EQ@mail.gmail.com>
 <5BABCDDD.5080403@oracle.com>
 <CAKjRUT7jb7tqAEpmkFbCrg=Vn29Q3NfcKZ5zm0JsFS0R59UocQ@mail.gmail.com>
 <CAKjRUT6qt1MkYcs+-3zE+yv0jrnRVt4_Fjcj=n=D+zZDgsiUKg@mail.gmail.com>
Message-ID: <280e74f7-7ca1-8fc0-9912-412c0229658b@oracle.com>

Thanks for the profiles.

I can't tell - from the profile - or even from [just looking at] the pdfbox
source what might be causing it to behave differently or why
it adds up to so much slower.

"Full stack" debugging - meaning building pdfbox seems to be necessary.
So I think that it might be best that if the pdfbox devs. do the initial 
evaluation.
Else it will wait a long time ...

-phil.

On 10/01/2018 10:52 AM, Laurent Bourg?s wrote:
> Hi,
> I quickly run your test with Oracle JDK8 and OpenJDK 11:
> Here are the CPU profiles:
> http://cr.openjdk.java.net/~lbourges/pdfbox_profiles/ 
> <http://cr.openjdk.java.net/%7Elbourges/pdfbox_profiles/>
>
> On JDK8:
> java version "1.8.0_192-ea"
> Java(TM) SE Runtime Environment (build 1.8.0_192-ea-b04)
> Java HotSpot(TM) 64-Bit Server VM (build 25.192-b04, mixed mode)
> Rendered 1 page in 3375ms
>
> ?777 ms 
> org.apache.pdfbox.pdmodel.graphics.image.SampledImageReader.getRGBImage
> ? 17.8% - 766 ms
> org.apache.pdfbox.pdmodel.graphics.image.SampledImageReader.from8bit
> ? 12.6% - 541 ms
> org.apache.pdfbox.pdmodel.graphics.image.PDImageXObject.createInputStream
> ? 12.6% - 541 ms 
> org.apache.pdfbox.pdmodel.common.PDStream.createInputStream
>
> On JDK11:
>
> openjdk version "11" 2018-09-25
> OpenJDK Runtime Environment 18.9 (build 11+28)
> OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)
> Rendered 1 page in 4789ms
>
> 2,059 ms 
> org.apache.pdfbox.pdmodel.graphics.image.SampledImageReader.getRGBImage
> ? 36.0% - 2,054 ms
> org.apache.pdfbox.pdmodel.graphics.image.SampledImageReader.from8bit
> ? 26.2% - 1,495 ms
> org.apache.pdfbox.pdmodel.graphics.color.PDDeviceCMYK.toRGBImage
> ? 26.2% - 1,495 ms
> org.apache.pdfbox.pdmodel.graphics.color.PDDeviceCMYK.toRGBImageAWT
> ? 26.2% - 1,495 ms
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.toRGBImageAWT
> ? 26.0% - 1,481 ms java.awt.image.ColorConvertOp.filter
>
> Actually, pdfbox's SampledImageReader.from8bit() do not use the same
> path between JDK8 and JDK11... and ColorConvertOp costs 25% (in my
> case)
>
> Cheers,
> Laurent
>
> Le jeu. 27 sept. 2018 ? 09:19, Laurent Bourg?s 
> <bourges.laurent at gmail.com <mailto:bourges.laurent at gmail.com>> a ?crit?:
>
>     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 <philip.race at oracle.com
>     <mailto:philip.race at oracle.com>> a ?crit?:
>
>         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 10%
>         to 29% ?
>
>         But even that doesn't on it own account for everything.
>         29% of 8 seconds would be about 2.5 seconds and doesn't
>         explain going from
>         < 3 seconds to 8 seconds .. we are still missing at least 2.5
>         seconds ..
>
>
>         -phil.
>
>         On 9/26/18, 11:08 AM, Daniel Persson wrote:
>>         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 <philip.race at oracle.com
>>         <mailto:philip.race at oracle.com>> wrote:
>>
>>             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 got so much better than 9? .. even if still not
>>             back to JDK 8.
>>
>>             Please file a bug at java.com <http://java.com>.
>>
>>             -phil.
>>
>>             On 09/25/2018 10:42 PM, Daniel Persson wrote:
>>             > Hi everyone,
>>             >
>>             > We render a lot of images with PDFBox with Java 1.8.0
>>             and we want to
>>             > upgrade to the current OpenJDK 11 but sadly we see some
>>             performance
>>             > degradation switching over to OpenJDK. Anyone have a
>>             suggestion to
>>             > remedy this issue, or can explain why it is slower?
>>             >
>>             > Using the PDFBox app current release downloadable from
>>             >
>>             http://www-us.apache.org/dist/pdfbox/2.0.11/pdfbox-app-2.0.11.jar
>>             >
>>             > Running the command
>>             > java -jar pdfbox-app-2.0.11.jar PDFToImage -time test.pdf
>>             >
>>             > We see the following result
>>             >
>>             > ---------------------------------------------------------
>>             > java version "1.8.0_181"
>>             > Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
>>             > Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13,
>>             mixed mode)
>>             > Rendered 1 page in 2762ms
>>             > ---------------------------------------------------------
>>             > openjdk version "9.0.4"
>>             > OpenJDK Runtime Environment (build 9.0.4+11)
>>             > OpenJDK 64-Bit Server VM (build 9.0.4+11, mixed mode)
>>             > Rendered 1 page in 8034ms
>>             > ---------------------------------------------------------
>>             > openjdk version "10.0.2" 2018-07-17
>>             > OpenJDK Runtime Environment 18.3 (build 10.0.2+13)
>>             > OpenJDK 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode)
>>             > Rendered 1 page in 4255ms
>>             > ---------------------------------------------------------
>>             > openjdk version "11" 2018-09-25
>>             > OpenJDK Runtime Environment 18.9 (build 11+28)
>>             > OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)
>>             > Rendered 1 page in 4275ms
>>             > ---------------------------------------------------------
>>             > openjdk version "12-ea" 2019-03-19
>>             > OpenJDK Runtime Environment 19.3 (build 12-ea+11)
>>             > OpenJDK 64-Bit Server VM 19.3 (build 12-ea+11, mixed mode)
>>             > Rendered 1 page in 4399ms
>>             >
>>             > The pdf file used in this example can be downloaded from
>>             >
>>             https://drive.google.com/file/d/139wP6PDmmQ6KBTyeJTETIrplSuOUgFfG/view?usp=sharing
>>             >
>>             > Best regards
>>             > Daniel
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181001/736f298b/attachment.html>

From philip.race at oracle.com  Mon Oct  1 22:09:32 2018
From: philip.race at oracle.com (Philip Race)
Date: Mon, 01 Oct 2018 15:09:32 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> [12]RFR: [JDK-8074824]: Resolve
 disabled warnings for libawt_xawt
In-Reply-To: <5BB24D6E.5020600@oracle.com>
References: <57768c04-a994-46f8-8322-fa89058d58c9@default>
 <5BB2491B.7000501@oracle.com> <5BB24D6E.5020600@oracle.com>
Message-ID: <5BB29B1C.3030601@oracle.com>

I suspect I understand this one now .. the array is stack allocated so 
we don't want NULL
but the compiler probably complained about possible uninitialised use of 
the values ?

-phil.

On 10/1/18, 9:38 AM, Philip Race wrote:
> You really do need to explain *each* of the changes better.
> This one .. why not NULL ?
> http://cr.openjdk.java.net/~kaddepalli/8074824/webrev01/src/java.desktop/share/native/libawt/java2d/loops/ProcessPath.c.udiff.html
>
> -phil
>
> On 10/1/18, 9:19 AM, Philip Race wrote:
>> Hi,
>>
>> 1) Has this been built on all platforms ?
>> 2)  I can't find the list of warnings that you are seeing and fixing 
>> and they are all over the place.
>> So adding 2d-dev and build-dev.
>> For each of these changes, please show what was the warning that you 
>> received from the compiler
>> This might sound like a lot of work, but it won't be disproportionate 
>> and I've made the same
>> request for similar reviews and without it, it is hard to review the 
>> changes.
>>
>> For example (and I do mean just example)
>> http://cr.openjdk.java.net/~kaddepalli/8074824/webrev01/src/java.desktop/unix/native/common/awt/awt_Font.c.udiff.html
>>
>> why would that not be #ifdef instead ?
>>
>> 3) Testing .. did you run at least all our jtreg tests to make sure 
>> you didn't break
>> some behaviour ..
>>
>> -phil.
>>
>> On 9/29/18, 8:18 PM, Krishna Addepalli wrote:
>>>
>>> Hi All,
>>>
>>> Please review a fix for JDK-8074824: 
>>> https://bugs.openjdk.java.net/browse/JDK-8074824
>>>
>>> Webrev: http://cr.openjdk.java.net/~kaddepalli/8074824/webrev01/ 
>>> <http://cr.openjdk.java.net/%7Ekaddepalli/8074824/webrev01/>
>>>
>>> Most of the warnings have been fixed for Linux, Mac and Windows.
>>>
>>> Thanks,
>>>
>>> Krishna
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181001/573b00ad/attachment-0001.html>

From amaembo at gmail.com  Mon Oct  1 22:57:36 2018
From: amaembo at gmail.com (Tagir Valeev)
Date: Tue, 2 Oct 2018 05:57:36 +0700
Subject: [OpenJDK 2D-Dev] RFR JDK-8211300: Convert C-style array
 declarations in Java code
In-Reply-To: <5BB24F07.1010806@oracle.com>
References: <CAE+3fjZo1t6fGpSZiK09Sf1se6f8uPwmfda3A9qyVr89BkDdgg@mail.gmail.com>
 <5BB24F07.1010806@oracle.com>
Message-ID: <CAE+3fjYEXTayj-LfVwNfj0fp7mHdUeTreHnTFjpK5uXR1xHqAg@mail.gmail.com>

Hello, Philip!

No, I didn't submit a job. Please do it. Thanks!

With best regards,
Tagir Valeev.


??, 1 ???. 2018 ?., 23:45 Philip Race <philip.race at oracle.com>:

> Hi,
>
> On 9/30/18, 8:29 PM, Tagir Valeev wrote:
> > Hello!
> >
> > Please review JDK-8211300 [1] this change: [2]. Also it needs a
> > sponsor as I have only JDK author status in OpenJDK Census [3].
>
> Adding awt + swing.
> I can sponsor this. Have you submitted a build via
> hg.openjdk.java.net/jdk/submit ?
> I can submit a job if you have not.
> I have also made a few updates to the bug report.
>
> -phil.
> >
> > The discussion in core-libs-dev [4] shows that it's desired to get rid
> > of old style array declarations like `int array[]` and massively
> > convert them to `int[] array`. I volunteered to work on this. As Alan
> > Bateman noted [5], java.desktop module is pushed to separate repo, so
> > it would be better to process it separately, thus I'd like to start
> > with it.
> >
> > The changeset was created in the following steps:
> > * Import JDK sources to IntelliJ IDEA
> > * Mark java.desktop/aix/classes, java.desktop/macosx/classes,
> > java.desktop/unix/classes, java.desktop/solaris/classes,
> > java.desktop/windows/classes and java.desktop/share/classes as source
> > roots
> > * Disable automatic formatting on the whole project
> > * Run the inspection "C-style array declaration"
> > * Apply the quick-fix massively
> > * Perform regex replace over changed files only:
> > Search: Copyright \(c\) (\d+), (\d+), Oracle and/or its affiliates.
> > All rights reserved.
> > Replace: Copyright \(c\) $1, 2018, Oracle and/or its affiliates. All
> > rights reserved.
> > * Perform regex replace over changed files only:
> > Search: Copyright \(c\) (\d+), Oracle and/or its affiliates. All
> > rights reserved.
> > Replace: Copyright \(c\) $1, 2018, Oracle and/or its affiliates. All
> > rights reserved.
> > * It appeared that compound declarations like `byte r[], g[], b[];`
> > are converted to `byte[] r;byte[] g; byte[] b;` which does not look
> > nice while compilable. I found three such cases via simple regexp
> > search in BMPImageReader#658, BMPImageWriter#325 and
> > AreaAveragingScaleFilter#66 and fixed them manually.
> >
> > In total 339 files were changed with 1335 lines of array declaration
> > updates and 310 lines of copyright updates. I reviewed the generated
> > patch by eyes, but only partially, because it's too big. Also I
> > performed some kind of simple sanity check using regexps:
> >
> > $ grep '^+[^+]' jdk.patch | grep -v 'Oracle and/or its affiliates. All
> > rights reserved'|grep -v '\[\]'|wc
> >        0       0       0
> > (check that every updated line contains either copyright message or [])
> >
> > With best regards,
> > Tagir Valeev.
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8211300
> > [2] http://cr.openjdk.java.net/~tvaleev/webrev/8211300/r1/
> > [3] http://openjdk.java.net/census#tvaleev
> > [4]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055390.html
> > [5]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055759.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181002/1744e025/attachment.html>

From Sergey.Bylokhov at oracle.com  Tue Oct  2 01:24:03 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 1 Oct 2018 18:24:03 -0700
Subject: [OpenJDK 2D-Dev] RFR JDK-8211300: Convert C-style array
 declarations in Java code
In-Reply-To: <CAE+3fjZo1t6fGpSZiK09Sf1se6f8uPwmfda3A9qyVr89BkDdgg@mail.gmail.com>
References: <CAE+3fjZo1t6fGpSZiK09Sf1se6f8uPwmfda3A9qyVr89BkDdgg@mail.gmail.com>
Message-ID: <7adc82ec-8a14-cf51-71f1-7fa04a4384e6@oracle.com>

Looks fine to me.
I have checked the patch, have build the change and run some tests on 
our supported platforms.

On 30/09/2018 20:29, Tagir Valeev wrote:
> Hello!
> 
> Please review JDK-8211300 [1] this change: [2]. Also it needs a
> sponsor as I have only JDK author status in OpenJDK Census [3].
> 
> The discussion in core-libs-dev [4] shows that it's desired to get rid
> of old style array declarations like `int array[]` and massively
> convert them to `int[] array`. I volunteered to work on this. As Alan
> Bateman noted [5], java.desktop module is pushed to separate repo, so
> it would be better to process it separately, thus I'd like to start
> with it.
> 
> The changeset was created in the following steps:
> * Import JDK sources to IntelliJ IDEA
> * Mark java.desktop/aix/classes, java.desktop/macosx/classes,
> java.desktop/unix/classes, java.desktop/solaris/classes,
> java.desktop/windows/classes and java.desktop/share/classes as source
> roots
> * Disable automatic formatting on the whole project
> * Run the inspection "C-style array declaration"
> * Apply the quick-fix massively
> * Perform regex replace over changed files only:
> Search: Copyright \(c\) (\d+), (\d+), Oracle and/or its affiliates.
> All rights reserved.
> Replace: Copyright \(c\) $1, 2018, Oracle and/or its affiliates. All
> rights reserved.
> * Perform regex replace over changed files only:
> Search: Copyright \(c\) (\d+), Oracle and/or its affiliates. All
> rights reserved.
> Replace: Copyright \(c\) $1, 2018, Oracle and/or its affiliates. All
> rights reserved.
> * It appeared that compound declarations like `byte r[], g[], b[];`
> are converted to `byte[] r;byte[] g; byte[] b;` which does not look
> nice while compilable. I found three such cases via simple regexp
> search in BMPImageReader#658, BMPImageWriter#325 and
> AreaAveragingScaleFilter#66 and fixed them manually.
> 
> In total 339 files were changed with 1335 lines of array declaration
> updates and 310 lines of copyright updates. I reviewed the generated
> patch by eyes, but only partially, because it's too big. Also I
> performed some kind of simple sanity check using regexps:
> 
> $ grep '^+[^+]' jdk.patch | grep -v 'Oracle and/or its affiliates. All
> rights reserved'|grep -v '\[\]'|wc
>        0       0       0
> (check that every updated line contains either copyright message or [])
> 
> With best regards,
> Tagir Valeev.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8211300
> [2] http://cr.openjdk.java.net/~tvaleev/webrev/8211300/r1/
> [3] http://openjdk.java.net/census#tvaleev
> [4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055390.html
> [5] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055759.html
> 


-- 
Best regards, Sergey.

From mailto.woden at gmail.com  Tue Oct  2 13:03:14 2018
From: mailto.woden at gmail.com (Daniel Persson)
Date: Tue, 2 Oct 2018 15:03:14 +0200
Subject: [OpenJDK 2D-Dev] Rendering images from PDF files slower in
	OpenJDK
In-Reply-To: <280e74f7-7ca1-8fc0-9912-412c0229658b@oracle.com>
References: <CALLYd6TyN2Fc+vFOrg9e-RA+M67G56gJ8E1jn+1CnFYkz6cKZg@mail.gmail.com>
 <3584070c-9406-b7a2-2d68-b485a0c1fcdd@oracle.com>
 <CALLYd6SC2+uEm4kVCZ1cLVm9EiKVnejcU+PwcmzZ0inPYRH3EQ@mail.gmail.com>
 <5BABCDDD.5080403@oracle.com>
 <CAKjRUT7jb7tqAEpmkFbCrg=Vn29Q3NfcKZ5zm0JsFS0R59UocQ@mail.gmail.com>
 <CAKjRUT6qt1MkYcs+-3zE+yv0jrnRVt4_Fjcj=n=D+zZDgsiUKg@mail.gmail.com>
 <280e74f7-7ca1-8fc0-9912-412c0229658b@oracle.com>
Message-ID: <CALLYd6QzQmvggNS7ajgkf2vsUc2zEFDnAN7z0ntZucPvOO475g@mail.gmail.com>

Hi Phil and Laurent

Let's not compare apples and oranges. What I can see it takes the same
route and behave similarly.

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.

If you want to see the full Call trees to check other eventual culprits you
can find them here.

http://uhash.com/java_reg/Call_Tree_java_8_full.html
http://uhash.com/java_reg/Call_Tree_java_11_full.html

Best regards
Daniel

On Mon, Oct 1, 2018 at 11:10 PM Phil Race <philip.race at oracle.com> wrote:

> Thanks for the profiles.
>
> I can't tell - from the profile - or even from [just looking at] the
> pdfbox
> source what might be causing it to behave differently or why
> it adds up to so much slower.
>
> "Full stack" debugging - meaning building pdfbox seems to be necessary.
> So I think that it might be best that if the pdfbox devs. do the initial
> evaluation.
> Else it will wait a long time ...
>
> -phil.
>
> On 10/01/2018 10:52 AM, Laurent Bourg?s wrote:
>
> Hi,
> I quickly run your test with Oracle JDK8 and OpenJDK 11:
> Here are the CPU profiles:
> http://cr.openjdk.java.net/~lbourges/pdfbox_profiles/
>
> On JDK8:
> java version "1.8.0_192-ea"
> Java(TM) SE Runtime Environment (build 1.8.0_192-ea-b04)
> Java HotSpot(TM) 64-Bit Server VM (build 25.192-b04, mixed mode)
> Rendered 1 page in 3375ms
>
>  777 ms org.apache.pdfbox.pdmodel.graphics.image.SampledImageReader.
> getRGBImage
>   17.8% - 766 ms
> org.apache.pdfbox.pdmodel.graphics.image.SampledImageReader.from8bit
>   12.6% - 541 ms
> org.apache.pdfbox.pdmodel.graphics.image.PDImageXObject.createInputStream
>   12.6% - 541 ms org.apache.pdfbox.pdmodel.comm
> on.PDStream.createInputStream
>
> On JDK11:
>
> openjdk version "11" 2018-09-25
> OpenJDK Runtime Environment 18.9 (build 11+28)
> OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)
> Rendered 1 page in 4789ms
>
> 2,059 ms org.apache.pdfbox.pdmodel.graphics.image.SampledImageReader.
> getRGBImage
>   36.0% - 2,054 ms
> org.apache.pdfbox.pdmodel.graphics.image.SampledImageReader.from8bit
>   26.2% - 1,495 ms
> org.apache.pdfbox.pdmodel.graphics.color.PDDeviceCMYK.toRGBImage
>   26.2% - 1,495 ms
> org.apache.pdfbox.pdmodel.graphics.color.PDDeviceCMYK.toRGBImageAWT
>   26.2% - 1,495 ms
> org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.toRGBImageAWT
>   26.0% - 1,481 ms java.awt.image.ColorConvertOp.filter
>
> Actually, pdfbox's SampledImageReader.from8bit() do not use the same
> path between JDK8 and JDK11... and ColorConvertOp costs 25% (in my
> case)
>
> Cheers,
> Laurent
>
> Le jeu. 27 sept. 2018 ? 09:19, Laurent Bourg?s <bourges.laurent at gmail.com>
> a ?crit :
>
>> 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 <philip.race at oracle.com> a
>> ?crit :
>>
>>> 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 10% to 29% ?
>>>
>>> But even that doesn't on it own account for everything.
>>> 29% of 8 seconds would be about 2.5 seconds and doesn't explain going
>>> from
>>> < 3 seconds to 8 seconds .. we are still missing at least 2.5 seconds ..
>>>
>>>
>>> -phil.
>>>
>>> On 9/26/18, 11:08 AM, Daniel Persson wrote:
>>>
>>> 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 <philip.race at oracle.com> wrote:
>>>
>>>> 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 got so much better than 9  .. even if still not back to JDK 8.
>>>>
>>>> Please file a bug at java.com.
>>>>
>>>> -phil.
>>>>
>>>> On 09/25/2018 10:42 PM, Daniel Persson wrote:
>>>> > Hi everyone,
>>>> >
>>>> > We render a lot of images with PDFBox with Java 1.8.0 and we want to
>>>> > upgrade to the current OpenJDK 11 but sadly we see some performance
>>>> > degradation switching over to OpenJDK. Anyone have a suggestion to
>>>> > remedy this issue, or can explain why it is slower?
>>>> >
>>>> > Using the PDFBox app current release downloadable from
>>>> > http://www-us.apache.org/dist/pdfbox/2.0.11/pdfbox-app-2.0.11.jar
>>>> >
>>>> > Running the command
>>>> > java -jar pdfbox-app-2.0.11.jar PDFToImage -time test.pdf
>>>> >
>>>> > We see the following result
>>>> >
>>>> > ---------------------------------------------------------
>>>> > java version "1.8.0_181"
>>>> > Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
>>>> > Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
>>>> > Rendered 1 page in 2762ms
>>>> > ---------------------------------------------------------
>>>> > openjdk version "9.0.4"
>>>> > OpenJDK Runtime Environment (build 9.0.4+11)
>>>> > OpenJDK 64-Bit Server VM (build 9.0.4+11, mixed mode)
>>>> > Rendered 1 page in 8034ms
>>>> > ---------------------------------------------------------
>>>> > openjdk version "10.0.2" 2018-07-17
>>>> > OpenJDK Runtime Environment 18.3 (build 10.0.2+13)
>>>> > OpenJDK 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode)
>>>> > Rendered 1 page in 4255ms
>>>> > ---------------------------------------------------------
>>>> > openjdk version "11" 2018-09-25
>>>> > OpenJDK Runtime Environment 18.9 (build 11+28)
>>>> > OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)
>>>> > Rendered 1 page in 4275ms
>>>> > ---------------------------------------------------------
>>>> > openjdk version "12-ea" 2019-03-19
>>>> > OpenJDK Runtime Environment 19.3 (build 12-ea+11)
>>>> > OpenJDK 64-Bit Server VM 19.3 (build 12-ea+11, mixed mode)
>>>> > Rendered 1 page in 4399ms
>>>> >
>>>> > The pdf file used in this example can be downloaded from
>>>> >
>>>> https://drive.google.com/file/d/139wP6PDmmQ6KBTyeJTETIrplSuOUgFfG/view?usp=sharing
>>>> >
>>>> > Best regards
>>>> > Daniel
>>>>
>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181002/e24547c0/attachment.html>

From krishna.addepalli at oracle.com  Tue Oct  2 15:23:24 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Tue, 2 Oct 2018 20:53:24 +0530
Subject: [OpenJDK 2D-Dev] <AWT Dev> [12]RFR: [JDK-8074824]: Resolve
 disabled warnings for libawt_xawt
In-Reply-To: <5BB29B1C.3030601@oracle.com>
References: <57768c04-a994-46f8-8322-fa89058d58c9@default>
 <5BB2491B.7000501@oracle.com> <5BB24D6E.5020600@oracle.com>
 <5BB29B1C.3030601@oracle.com>
Message-ID: <F5D651AC-DFCD-41A5-8465-ACC425E7DE2D@oracle.com>

Yes, that is right.
I have compiled it Mac, Linux and Windows locally. I tried submitting a Mach5 job, but was unable to as it was down. Will try it again.

Thanks
Krishna

> On 02-Oct-2018, at 3:39 AM, Philip Race <philip.race at oracle.com> wrote:
> 
> I suspect I understand this one now .. the array is stack allocated so we don't want NULL
> but the compiler probably complained about possible uninitialised use of the values ?
> 
> -phil.
> 
> On 10/1/18, 9:38 AM, Philip Race wrote:
>> 
>> You really do need to explain *each* of the changes better.
>> This one .. why not NULL ?
>> http://cr.openjdk.java.net/~kaddepalli/8074824/webrev01/src/java.desktop/share/native/libawt/java2d/loops/ProcessPath.c.udiff.html <http://cr.openjdk.java.net/%7Ekaddepalli/8074824/webrev01/src/java.desktop/share/native/libawt/java2d/loops/ProcessPath.c.udiff.html>
>> 
>> -phil
>> 
>> On 10/1/18, 9:19 AM, Philip Race wrote:
>>> 
>>> Hi,
>>> 
>>> 1) Has this been built on all platforms ?
>>> 2)  I can't find the list of warnings that you are seeing and fixing and they are all over the place.
>>> So adding 2d-dev and build-dev.
>>> For each of these changes, please show what was the warning that you received from the compiler
>>> This might sound like a lot of work, but it won't be disproportionate and I've made the same
>>> request for similar reviews and without it, it is hard to review the changes.
>>> 
>>> For example (and I do mean just example) 
>>> http://cr.openjdk.java.net/~kaddepalli/8074824/webrev01/src/java.desktop/unix/native/common/awt/awt_Font.c.udiff.html <http://cr.openjdk.java.net/%7Ekaddepalli/8074824/webrev01/src/java.desktop/unix/native/common/awt/awt_Font.c.udiff.html>
>>> 
>>> why would that not be #ifdef instead ?
>>> 
>>> 3) Testing .. did you run at least all our jtreg tests to make sure you didn't break
>>> some behaviour ..
>>> 
>>> -phil.
>>> 
>>> On 9/29/18, 8:18 PM, Krishna Addepalli wrote:
>>>> 
>>>> Hi All, 
>>>>  
>>>> Please review a fix for JDK-8074824: https://bugs.openjdk.java.net/browse/JDK-8074824 <https://bugs.openjdk.java.net/browse/JDK-8074824>
>>>> Webrev: http://cr.openjdk.java.net/~kaddepalli/8074824/webrev01/ <http://cr.openjdk.java.net/%7Ekaddepalli/8074824/webrev01/>
>>>>  
>>>> Most of the warnings have been fixed for Linux, Mac and Windows.
>>>>  
>>>> Thanks,
>>>> Krishna

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181002/eea8c2f4/attachment-0001.html>

From bourges.laurent at gmail.com  Tue Oct  2 16:35:58 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Tue, 2 Oct 2018 18:35:58 +0200
Subject: [OpenJDK 2D-Dev] Rendering images from PDF files slower in
	OpenJDK
In-Reply-To: <CALLYd6QzQmvggNS7ajgkf2vsUc2zEFDnAN7z0ntZucPvOO475g@mail.gmail.com>
References: <CALLYd6TyN2Fc+vFOrg9e-RA+M67G56gJ8E1jn+1CnFYkz6cKZg@mail.gmail.com>
 <3584070c-9406-b7a2-2d68-b485a0c1fcdd@oracle.com>
 <CALLYd6SC2+uEm4kVCZ1cLVm9EiKVnejcU+PwcmzZ0inPYRH3EQ@mail.gmail.com>
 <5BABCDDD.5080403@oracle.com>
 <CAKjRUT7jb7tqAEpmkFbCrg=Vn29Q3NfcKZ5zm0JsFS0R59UocQ@mail.gmail.com>
 <CAKjRUT6qt1MkYcs+-3zE+yv0jrnRVt4_Fjcj=n=D+zZDgsiUKg@mail.gmail.com>
 <280e74f7-7ca1-8fc0-9912-412c0229658b@oracle.com>
 <CALLYd6QzQmvggNS7ajgkf2vsUc2zEFDnAN7z0ntZucPvOO475g@mail.gmail.com>
Message-ID: <CAKjRUT4YQp+6d=z_RSQ2ufrRtwmVA-308LFxowoQ3ewuXSyJ8A@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181002/4705aa49/attachment.html>

From philip.race at oracle.com  Tue Oct  2 21:35:35 2018
From: philip.race at oracle.com (Philip Race)
Date: Tue, 2 Oct 2018 14:35:35 -0700
Subject: [OpenJDK 2D-Dev] Rendering images from PDF files slower in
 OpenJDK
In-Reply-To: <CAKjRUT4YQp+6d=z_RSQ2ufrRtwmVA-308LFxowoQ3ewuXSyJ8A@mail.gmail.com>
References: <CALLYd6TyN2Fc+vFOrg9e-RA+M67G56gJ8E1jn+1CnFYkz6cKZg@mail.gmail.com>
 <3584070c-9406-b7a2-2d68-b485a0c1fcdd@oracle.com>
 <CALLYd6SC2+uEm4kVCZ1cLVm9EiKVnejcU+PwcmzZ0inPYRH3EQ@mail.gmail.com>
 <5BABCDDD.5080403@oracle.com>
 <CAKjRUT7jb7tqAEpmkFbCrg=Vn29Q3NfcKZ5zm0JsFS0R59UocQ@mail.gmail.com>
 <CAKjRUT6qt1MkYcs+-3zE+yv0jrnRVt4_Fjcj=n=D+zZDgsiUKg@mail.gmail.com>
 <280e74f7-7ca1-8fc0-9912-412c0229658b@oracle.com>
 <CALLYd6QzQmvggNS7ajgkf2vsUc2zEFDnAN7z0ntZucPvOO475g@mail.gmail.com>
 <CAKjRUT4YQp+6d=z_RSQ2ufrRtwmVA-308LFxowoQ3ewuXSyJ8A@mail.gmail.com>
Message-ID: <873cc9de-604f-8b11-a5ba-fcccf4337e81@oracle.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181002/a5cdb624/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CConv.java
Type: text/x-java
Size: 1491 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181002/a5cdb624/CConv.java>

From philip.race at oracle.com  Wed Oct  3 00:01:12 2018
From: philip.race at oracle.com (Philip Race)
Date: Tue, 02 Oct 2018 17:01:12 -0700
Subject: [OpenJDK 2D-Dev] [12] RFR JDK-8211055:Provide print to a file
 (PDF) feature even when printer was not connected
In-Reply-To: <bd6d11b8-a7fd-241f-89d7-49e9ebfeb929@oracle.com>
References: <8af8c638-c259-d5c5-111b-3df2e8cc20ce@oracle.com>
 <07241a48-10e7-3073-4ea6-40f70ab41071@oracle.com>
 <bd6d11b8-a7fd-241f-89d7-49e9ebfeb929@oracle.com>
Message-ID: <5BB406C8.2020302@oracle.com>

Good enough to fix the regression.

+1

-phil.

On 9/26/18, 11:24 PM, Prasanta Sadhukhan wrote:
>
> I have added @requires tag and also did an initial check of existing 
> printers and exit if there is any.
>
> Regarding setting,retrieving Destination attribute, if we do not show 
> the print dialog and ask user to select file and ok,
> it will not set call nsPrintInfoToJavaPrinterJob which is called from 
> showDialog() and so NSPrintJobDispositionValuewill not be set up and 
> setPrintToFile() will not be called.
>
> I checked in jdk8GA too, it fails if we set Destination and try to 
> print. I guess existing customer issue is about not printing if user 
> manually selects "Save as PDF". I guess I can work on that issue as a 
> separate bug.
> Modified test 
> webrev:http://cr.openjdk.java.net/~psadhukhan/8211055/webrev.1/
>
> Regards
> Prasanta
> On 26-Sep-18 9:48 PM, Phil Race wrote:
>> This is all MacOS specific changes - and functionality - but the test 
>> seems
>> to be cross-platform. Shouldn't it at least have an @requires macos tag ?
>>
>> And I think the test should verify there are no printers and say it can't
>> be run if you have any ... and exit ...
>>
>> Can we set & retrieve the file as a Destination attribute ?
>> Then we can verify the file was saved without the user's help
>>
>>
>>   123             " 4. Another dialog opends prompting for filename, enter any filename and press \"Save\".\r\n" +
>>
>> opends -> opens
>>
>> -phil.
>>
>> On 09/26/2018 04:38 AM, Prasanta Sadhukhan wrote:
>>> Hi All,
>>>
>>> Please review a fix for an issue where it is seen that if we do not 
>>> have any printer installed and we try to save the printjob to a file
>>> via "Save as PDF" option in mac, it was throwing PrinterExcetion:no 
>>> printer service found.
>>>
>>> This is a regression of JDK-8132988 where a check was added to make 
>>> sure PrinterException is thrown if there is no printer installed.
>>> Proposed fix is to find out if user is selecting "Save as PDF" 
>>> option in native print dialog which will cause NSPrintInfo's 
>>> jobDisposition value to be |NSPrintSaveJob
>>> [https://developer.apple.com/documentation/appkit/nsprintinfo/1528717-jobdisposition?language=objc]
>>>
>>> |In that case, the previous "no-printer" check is amended to also 
>>> check if the print operation is saving to a file, in which case do 
>>> not throw PrinterException and proceed with Save-File operation.
>>> JDK-8132988  testcase also works ok after this fix.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8211055
>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8211055/webrev.0/
>>>
>>> Regards
>>> Prasanta
>>> || 
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181002/6141f593/attachment-0001.html>

From philip.race at oracle.com  Wed Oct  3 03:52:34 2018
From: philip.race at oracle.com (Philip Race)
Date: Tue, 02 Oct 2018 20:52:34 -0700
Subject: [OpenJDK 2D-Dev] RFR JDK-8211300: Convert C-style array
 declarations in Java code
In-Reply-To: <7adc82ec-8a14-cf51-71f1-7fa04a4384e6@oracle.com>
References: <CAE+3fjZo1t6fGpSZiK09Sf1se6f8uPwmfda3A9qyVr89BkDdgg@mail.gmail.com>
 <7adc82ec-8a14-cf51-71f1-7fa04a4384e6@oracle.com>
Message-ID: <5BB43D02.8000907@oracle.com>

Given what Sergey has done, I don't need to repeat that work.
I am now just looking for formatting anomalies, but there is a lot to 
look at.
I should be able to OK this tomorrow and we can then commit it on your 
behalf.

Have  you looked at the other client modules ? datatransfer, accessibility,
jdk.unsupported.desktop, or the client demos ?
If you are crazy (just an idea) then maybe even tests !
But that latter one is a low priority.

They surely also have some similar declarations.
I suggest unique bugs for each of those categories but it should all be MUCH
smaller ..  so maybe small enough to collapse.

BTW

 > It appeared that compound declarations like `byte r[], g[], b[];`
 > are converted to `byte[] r;byte[] g; byte[] b;

Seems like someone should fix their tool :-)

-phil.


On 10/1/18, 6:24 PM, Sergey Bylokhov wrote:
> Looks fine to me.
> I have checked the patch, have build the change and run some tests on 
> our supported platforms.
>
> On 30/09/2018 20:29, Tagir Valeev wrote:
>> Hello!
>>
>> Please review JDK-8211300 [1] this change: [2]. Also it needs a
>> sponsor as I have only JDK author status in OpenJDK Census [3].
>>
>> The discussion in core-libs-dev [4] shows that it's desired to get rid
>> of old style array declarations like `int array[]` and massively
>> convert them to `int[] array`. I volunteered to work on this. As Alan
>> Bateman noted [5], java.desktop module is pushed to separate repo, so
>> it would be better to process it separately, thus I'd like to start
>> with it.
>>
>> The changeset was created in the following steps:
>> * Import JDK sources to IntelliJ IDEA
>> * Mark java.desktop/aix/classes, java.desktop/macosx/classes,
>> java.desktop/unix/classes, java.desktop/solaris/classes,
>> java.desktop/windows/classes and java.desktop/share/classes as source
>> roots
>> * Disable automatic formatting on the whole project
>> * Run the inspection "C-style array declaration"
>> * Apply the quick-fix massively
>> * Perform regex replace over changed files only:
>> Search: Copyright \(c\) (\d+), (\d+), Oracle and/or its affiliates.
>> All rights reserved.
>> Replace: Copyright \(c\) $1, 2018, Oracle and/or its affiliates. All
>> rights reserved.
>> * Perform regex replace over changed files only:
>> Search: Copyright \(c\) (\d+), Oracle and/or its affiliates. All
>> rights reserved.
>> Replace: Copyright \(c\) $1, 2018, Oracle and/or its affiliates. All
>> rights reserved.
>> * It appeared that compound declarations like `byte r[], g[], b[];`
>> are converted to `byte[] r;byte[] g; byte[] b;` which does not look
>> nice while compilable. I found three such cases via simple regexp
>> search in BMPImageReader#658, BMPImageWriter#325 and
>> AreaAveragingScaleFilter#66 and fixed them manually.
>>
>> In total 339 files were changed with 1335 lines of array declaration
>> updates and 310 lines of copyright updates. I reviewed the generated
>> patch by eyes, but only partially, because it's too big. Also I
>> performed some kind of simple sanity check using regexps:
>>
>> $ grep '^+[^+]' jdk.patch | grep -v 'Oracle and/or its affiliates. All
>> rights reserved'|grep -v '\[\]'|wc
>>        0       0       0
>> (check that every updated line contains either copyright message or [])
>>
>> With best regards,
>> Tagir Valeev.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8211300
>> [2] http://cr.openjdk.java.net/~tvaleev/webrev/8211300/r1/
>> [3] http://openjdk.java.net/census#tvaleev
>> [4] 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055390.html
>> [5] 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055759.html
>>
>
>

From bourges.laurent at gmail.com  Wed Oct  3 08:15:35 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Wed, 3 Oct 2018 10:15:35 +0200
Subject: [OpenJDK 2D-Dev] Rendering images from PDF files slower in
	OpenJDK
In-Reply-To: <873cc9de-604f-8b11-a5ba-fcccf4337e81@oracle.com>
References: <CALLYd6TyN2Fc+vFOrg9e-RA+M67G56gJ8E1jn+1CnFYkz6cKZg@mail.gmail.com>
 <3584070c-9406-b7a2-2d68-b485a0c1fcdd@oracle.com>
 <CALLYd6SC2+uEm4kVCZ1cLVm9EiKVnejcU+PwcmzZ0inPYRH3EQ@mail.gmail.com>
 <5BABCDDD.5080403@oracle.com>
 <CAKjRUT7jb7tqAEpmkFbCrg=Vn29Q3NfcKZ5zm0JsFS0R59UocQ@mail.gmail.com>
 <CAKjRUT6qt1MkYcs+-3zE+yv0jrnRVt4_Fjcj=n=D+zZDgsiUKg@mail.gmail.com>
 <280e74f7-7ca1-8fc0-9912-412c0229658b@oracle.com>
 <CALLYd6QzQmvggNS7ajgkf2vsUc2zEFDnAN7z0ntZucPvOO475g@mail.gmail.com>
 <CAKjRUT4YQp+6d=z_RSQ2ufrRtwmVA-308LFxowoQ3ewuXSyJ8A@mail.gmail.com>
 <873cc9de-604f-8b11-a5ba-fcccf4337e81@oracle.com>
Message-ID: <CAKjRUT5XqGdVO10UDJK7VuS5nEo_p0pDohxm=GiMqosdzA7Tgw@mail.gmail.com>

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 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.race at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181003/2b1570d5/attachment.html>

From amaembo at gmail.com  Wed Oct  3 10:06:18 2018
From: amaembo at gmail.com (Tagir Valeev)
Date: Wed, 3 Oct 2018 17:06:18 +0700
Subject: [OpenJDK 2D-Dev] RFR JDK-8211300: Convert C-style array
 declarations in Java code
In-Reply-To: <5BB43D02.8000907@oracle.com>
References: <CAE+3fjZo1t6fGpSZiK09Sf1se6f8uPwmfda3A9qyVr89BkDdgg@mail.gmail.com>
 <7adc82ec-8a14-cf51-71f1-7fa04a4384e6@oracle.com>
 <5BB43D02.8000907@oracle.com>
Message-ID: <CAE+3fjZ7OydT4uWhcNZvBnFU6dqPb=RHv8PHHt6FyuxAisDAHQ@mail.gmail.com>

Hello!

> Given what Sergey has done, I don't need to repeat that work.
> I am now just looking for formatting anomalies, but there is a lot to
> look at.
> I should be able to OK this tomorrow and we can then commit it on your
> behalf.

Thanks, that would be great!

>
> Have  you looked at the other client modules ? datatransfer, accessibility,
> jdk.unsupported.desktop, or the client demos ?

No, I haven't. I was not aware that there are other client modules. I
assume that client demos are in src/demo/share directory, right?
I found no hits in datatransfer and jdk.unsupported.desktop, 4 files
in accessibility and 71 files in demos. Here's separate webrev for
these 75 files:
http://cr.openjdk.java.net/~tvaleev/patches/c_style_arrays_demos_accessibility/
Should I post a separate JBS issue for this (or two issues) or it
could be incorporated within existing issue?
Should I post separate reviews for accessibility and demos or it's
fine to have them together?

> If you are crazy (just an idea) then maybe even tests !
> But that latter one is a low priority.

Let's postpone tests. I'd like to move to some core modules like
java.base until my volunteering energy runs out :-)

>  > It appeared that compound declarations like `byte r[], g[], b[];`
>  > are converted to `byte[] r;byte[] g; byte[] b;
>
> Seems like someone should fix their tool :-)

Yeah, this is what I'm thinking about (I'm IDEA developer). See, IDEA
processes every hit separately, and we have three independent hits
here. So when it processes r[] it doesn't know that I want to convert
others as well, thus it has to split the compound declaration into
`byte[] r;byte g[], b[];` (when formatting is active, they are placed
on separate lines, but I switched off the formatting to simplify the
changeset). The same is repeated for `g` and `b` independently and we
have unpleasant result. Probably we can fix this issuing single
warning per declaration and suggesting to fix the whole declaration or
nothing (it's unlikely that somebody would like to fix only some of
these arrays), but then the question is which source element should be
highlighted. Now we highlight three pairs of brackets in three
individual warnings, but if we have a single warning, we should
highlight something continuous. We may highlight the whole
declaration, but what if it also contains non-convertible things like
`byte r[], g, b[]`. Looks like a simple problem, but I don't see the
trivial solution. But ok, it's an off-topic :-)

With best regards,
Tagir Valeev

>
> -phil.
>
>
> On 10/1/18, 6:24 PM, Sergey Bylokhov wrote:
> > Looks fine to me.
> > I have checked the patch, have build the change and run some tests on
> > our supported platforms.
> >
> > On 30/09/2018 20:29, Tagir Valeev wrote:
> >> Hello!
> >>
> >> Please review JDK-8211300 [1] this change: [2]. Also it needs a
> >> sponsor as I have only JDK author status in OpenJDK Census [3].
> >>
> >> The discussion in core-libs-dev [4] shows that it's desired to get rid
> >> of old style array declarations like `int array[]` and massively
> >> convert them to `int[] array`. I volunteered to work on this. As Alan
> >> Bateman noted [5], java.desktop module is pushed to separate repo, so
> >> it would be better to process it separately, thus I'd like to start
> >> with it.
> >>
> >> The changeset was created in the following steps:
> >> * Import JDK sources to IntelliJ IDEA
> >> * Mark java.desktop/aix/classes, java.desktop/macosx/classes,
> >> java.desktop/unix/classes, java.desktop/solaris/classes,
> >> java.desktop/windows/classes and java.desktop/share/classes as source
> >> roots
> >> * Disable automatic formatting on the whole project
> >> * Run the inspection "C-style array declaration"
> >> * Apply the quick-fix massively
> >> * Perform regex replace over changed files only:
> >> Search: Copyright \(c\) (\d+), (\d+), Oracle and/or its affiliates.
> >> All rights reserved.
> >> Replace: Copyright \(c\) $1, 2018, Oracle and/or its affiliates. All
> >> rights reserved.
> >> * Perform regex replace over changed files only:
> >> Search: Copyright \(c\) (\d+), Oracle and/or its affiliates. All
> >> rights reserved.
> >> Replace: Copyright \(c\) $1, 2018, Oracle and/or its affiliates. All
> >> rights reserved.
> >> * It appeared that compound declarations like `byte r[], g[], b[];`
> >> are converted to `byte[] r;byte[] g; byte[] b;` which does not look
> >> nice while compilable. I found three such cases via simple regexp
> >> search in BMPImageReader#658, BMPImageWriter#325 and
> >> AreaAveragingScaleFilter#66 and fixed them manually.
> >>
> >> In total 339 files were changed with 1335 lines of array declaration
> >> updates and 310 lines of copyright updates. I reviewed the generated
> >> patch by eyes, but only partially, because it's too big. Also I
> >> performed some kind of simple sanity check using regexps:
> >>
> >> $ grep '^+[^+]' jdk.patch | grep -v 'Oracle and/or its affiliates. All
> >> rights reserved'|grep -v '\[\]'|wc
> >>        0       0       0
> >> (check that every updated line contains either copyright message or [])
> >>
> >> With best regards,
> >> Tagir Valeev.
> >>
> >> [1] https://bugs.openjdk.java.net/browse/JDK-8211300
> >> [2] http://cr.openjdk.java.net/~tvaleev/webrev/8211300/r1/
> >> [3] http://openjdk.java.net/census#tvaleev
> >> [4]
> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055390.html
> >> [5]
> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055759.html
> >>
> >
> >

From philip.race at oracle.com  Wed Oct  3 17:19:18 2018
From: philip.race at oracle.com (Philip Race)
Date: Wed, 3 Oct 2018 10:19:18 -0700
Subject: [OpenJDK 2D-Dev] Rendering images from PDF files slower in
 OpenJDK
In-Reply-To: <CAKjRUT5XqGdVO10UDJK7VuS5nEo_p0pDohxm=GiMqosdzA7Tgw@mail.gmail.com>
References: <CALLYd6TyN2Fc+vFOrg9e-RA+M67G56gJ8E1jn+1CnFYkz6cKZg@mail.gmail.com>
 <3584070c-9406-b7a2-2d68-b485a0c1fcdd@oracle.com>
 <CALLYd6SC2+uEm4kVCZ1cLVm9EiKVnejcU+PwcmzZ0inPYRH3EQ@mail.gmail.com>
 <5BABCDDD.5080403@oracle.com>
 <CAKjRUT7jb7tqAEpmkFbCrg=Vn29Q3NfcKZ5zm0JsFS0R59UocQ@mail.gmail.com>
 <CAKjRUT6qt1MkYcs+-3zE+yv0jrnRVt4_Fjcj=n=D+zZDgsiUKg@mail.gmail.com>
 <280e74f7-7ca1-8fc0-9912-412c0229658b@oracle.com>
 <CALLYd6QzQmvggNS7ajgkf2vsUc2zEFDnAN7z0ntZucPvOO475g@mail.gmail.com>
 <CAKjRUT4YQp+6d=z_RSQ2ufrRtwmVA-308LFxowoQ3ewuXSyJ8A@mail.gmail.com>
 <873cc9de-604f-8b11-a5ba-fcccf4337e81@oracle.com>
 <CAKjRUT5XqGdVO10UDJK7VuS5nEo_p0pDohxm=GiMqosdzA7Tgw@mail.gmail.com>
Message-ID: <a281fd1e-2702-1de3-b4df-823fb3f6c2b2@oracle.com>



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.race at oracle.com 
> <mailto:philip.race at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181003/96ad18c0/attachment.html>

From bourges.laurent at gmail.com  Wed Oct  3 17:51:10 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Wed, 3 Oct 2018 19:51:10 +0200
Subject: [OpenJDK 2D-Dev] Rendering images from PDF files slower in
	OpenJDK
In-Reply-To: <a281fd1e-2702-1de3-b4df-823fb3f6c2b2@oracle.com>
References: <CALLYd6TyN2Fc+vFOrg9e-RA+M67G56gJ8E1jn+1CnFYkz6cKZg@mail.gmail.com>
 <3584070c-9406-b7a2-2d68-b485a0c1fcdd@oracle.com>
 <CALLYd6SC2+uEm4kVCZ1cLVm9EiKVnejcU+PwcmzZ0inPYRH3EQ@mail.gmail.com>
 <5BABCDDD.5080403@oracle.com>
 <CAKjRUT7jb7tqAEpmkFbCrg=Vn29Q3NfcKZ5zm0JsFS0R59UocQ@mail.gmail.com>
 <CAKjRUT6qt1MkYcs+-3zE+yv0jrnRVt4_Fjcj=n=D+zZDgsiUKg@mail.gmail.com>
 <280e74f7-7ca1-8fc0-9912-412c0229658b@oracle.com>
 <CALLYd6QzQmvggNS7ajgkf2vsUc2zEFDnAN7z0ntZucPvOO475g@mail.gmail.com>
 <CAKjRUT4YQp+6d=z_RSQ2ufrRtwmVA-308LFxowoQ3ewuXSyJ8A@mail.gmail.com>
 <873cc9de-604f-8b11-a5ba-fcccf4337e81@oracle.com>
 <CAKjRUT5XqGdVO10UDJK7VuS5nEo_p0pDohxm=GiMqosdzA7Tgw@mail.gmail.com>
 <a281fd1e-2702-1de3-b4df-823fb3f6c2b2@oracle.com>
Message-ID: <CAKjRUT5U1=EqYNpM64Wr-GmX2WKnjC5VThOcnSNEgvQi2zg1ew@mail.gmail.com>

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.race at 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.race at 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181003/faaf7c3f/attachment-0001.html>

From philip.race at oracle.com  Wed Oct  3 23:03:49 2018
From: philip.race at oracle.com (Phil Race)
Date: Wed, 3 Oct 2018 16:03:49 -0700
Subject: [OpenJDK 2D-Dev] RFR JDK-8211300: Convert C-style array
 declarations in Java code
In-Reply-To: <CAE+3fjZ7OydT4uWhcNZvBnFU6dqPb=RHv8PHHt6FyuxAisDAHQ@mail.gmail.com>
References: <CAE+3fjZo1t6fGpSZiK09Sf1se6f8uPwmfda3A9qyVr89BkDdgg@mail.gmail.com>
 <7adc82ec-8a14-cf51-71f1-7fa04a4384e6@oracle.com>
 <5BB43D02.8000907@oracle.com>
 <CAE+3fjZ7OydT4uWhcNZvBnFU6dqPb=RHv8PHHt6FyuxAisDAHQ@mail.gmail.com>
Message-ID: <464e5543-2f6c-6609-cf40-9208d2b8bc44@oracle.com>

The indentation now looks inconsistent in these two files. Maybe we can 
manually fix that up ?

http://cr.openjdk.java.net/~tvaleev/webrev/8211300/r1/src/java.desktop/share/classes/javax/swing/tree/FixedHeightLayoutCache.java.udiff.html
http://cr.openjdk.java.net/~tvaleev/webrev/8211300/r1/src/java.desktop/share/classes/javax/swing/tree/VariableHeightLayoutCache.java.udiff.html

Sergey, are you going to commit this, or am I ?

The changes in demos + accessibility are best handled under a different 
bug id since
this one is quite far along ..

-phil.

On 10/03/2018 03:06 AM, Tagir Valeev wrote:
> Hello!
>
>> Given what Sergey has done, I don't need to repeat that work.
>> I am now just looking for formatting anomalies, but there is a lot to
>> look at.
>> I should be able to OK this tomorrow and we can then commit it on your
>> behalf.
> Thanks, that would be great!
>
>> Have  you looked at the other client modules ? datatransfer, accessibility,
>> jdk.unsupported.desktop, or the client demos ?
> No, I haven't. I was not aware that there are other client modules. I
> assume that client demos are in src/demo/share directory, right?
> I found no hits in datatransfer and jdk.unsupported.desktop, 4 files
> in accessibility and 71 files in demos. Here's separate webrev for
> these 75 files:
> http://cr.openjdk.java.net/~tvaleev/patches/c_style_arrays_demos_accessibility/
> Should I post a separate JBS issue for this (or two issues) or it
> could be incorporated within existing issue?
> Should I post separate reviews for accessibility and demos or it's
> fine to have them together?
>
>> If you are crazy (just an idea) then maybe even tests !
>> But that latter one is a low priority.
> Let's postpone tests. I'd like to move to some core modules like
> java.base until my volunteering energy runs out :-)
>
>>   > It appeared that compound declarations like `byte r[], g[], b[];`
>>   > are converted to `byte[] r;byte[] g; byte[] b;
>>
>> Seems like someone should fix their tool :-)
> Yeah, this is what I'm thinking about (I'm IDEA developer). See, IDEA
> processes every hit separately, and we have three independent hits
> here. So when it processes r[] it doesn't know that I want to convert
> others as well, thus it has to split the compound declaration into
> `byte[] r;byte g[], b[];` (when formatting is active, they are placed
> on separate lines, but I switched off the formatting to simplify the
> changeset). The same is repeated for `g` and `b` independently and we
> have unpleasant result. Probably we can fix this issuing single
> warning per declaration and suggesting to fix the whole declaration or
> nothing (it's unlikely that somebody would like to fix only some of
> these arrays), but then the question is which source element should be
> highlighted. Now we highlight three pairs of brackets in three
> individual warnings, but if we have a single warning, we should
> highlight something continuous. We may highlight the whole
> declaration, but what if it also contains non-convertible things like
> `byte r[], g, b[]`. Looks like a simple problem, but I don't see the
> trivial solution. But ok, it's an off-topic :-)
>
> With best regards,
> Tagir Valeev
>
>> -phil.
>>
>>
>> On 10/1/18, 6:24 PM, Sergey Bylokhov wrote:
>>> Looks fine to me.
>>> I have checked the patch, have build the change and run some tests on
>>> our supported platforms.
>>>
>>> On 30/09/2018 20:29, Tagir Valeev wrote:
>>>> Hello!
>>>>
>>>> Please review JDK-8211300 [1] this change: [2]. Also it needs a
>>>> sponsor as I have only JDK author status in OpenJDK Census [3].
>>>>
>>>> The discussion in core-libs-dev [4] shows that it's desired to get rid
>>>> of old style array declarations like `int array[]` and massively
>>>> convert them to `int[] array`. I volunteered to work on this. As Alan
>>>> Bateman noted [5], java.desktop module is pushed to separate repo, so
>>>> it would be better to process it separately, thus I'd like to start
>>>> with it.
>>>>
>>>> The changeset was created in the following steps:
>>>> * Import JDK sources to IntelliJ IDEA
>>>> * Mark java.desktop/aix/classes, java.desktop/macosx/classes,
>>>> java.desktop/unix/classes, java.desktop/solaris/classes,
>>>> java.desktop/windows/classes and java.desktop/share/classes as source
>>>> roots
>>>> * Disable automatic formatting on the whole project
>>>> * Run the inspection "C-style array declaration"
>>>> * Apply the quick-fix massively
>>>> * Perform regex replace over changed files only:
>>>> Search: Copyright \(c\) (\d+), (\d+), Oracle and/or its affiliates.
>>>> All rights reserved.
>>>> Replace: Copyright \(c\) $1, 2018, Oracle and/or its affiliates. All
>>>> rights reserved.
>>>> * Perform regex replace over changed files only:
>>>> Search: Copyright \(c\) (\d+), Oracle and/or its affiliates. All
>>>> rights reserved.
>>>> Replace: Copyright \(c\) $1, 2018, Oracle and/or its affiliates. All
>>>> rights reserved.
>>>> * It appeared that compound declarations like `byte r[], g[], b[];`
>>>> are converted to `byte[] r;byte[] g; byte[] b;` which does not look
>>>> nice while compilable. I found three such cases via simple regexp
>>>> search in BMPImageReader#658, BMPImageWriter#325 and
>>>> AreaAveragingScaleFilter#66 and fixed them manually.
>>>>
>>>> In total 339 files were changed with 1335 lines of array declaration
>>>> updates and 310 lines of copyright updates. I reviewed the generated
>>>> patch by eyes, but only partially, because it's too big. Also I
>>>> performed some kind of simple sanity check using regexps:
>>>>
>>>> $ grep '^+[^+]' jdk.patch | grep -v 'Oracle and/or its affiliates. All
>>>> rights reserved'|grep -v '\[\]'|wc
>>>>         0       0       0
>>>> (check that every updated line contains either copyright message or [])
>>>>
>>>> With best regards,
>>>> Tagir Valeev.
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8211300
>>>> [2] http://cr.openjdk.java.net/~tvaleev/webrev/8211300/r1/
>>>> [3] http://openjdk.java.net/census#tvaleev
>>>> [4]
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055390.html
>>>> [5]
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055759.html
>>>>
>>>


From Sergey.Bylokhov at oracle.com  Wed Oct  3 23:09:49 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 3 Oct 2018 16:09:49 -0700
Subject: [OpenJDK 2D-Dev] RFR JDK-8211300: Convert C-style array
 declarations in Java code
In-Reply-To: <464e5543-2f6c-6609-cf40-9208d2b8bc44@oracle.com>
References: <CAE+3fjZo1t6fGpSZiK09Sf1se6f8uPwmfda3A9qyVr89BkDdgg@mail.gmail.com>
 <7adc82ec-8a14-cf51-71f1-7fa04a4384e6@oracle.com>
 <5BB43D02.8000907@oracle.com>
 <CAE+3fjZ7OydT4uWhcNZvBnFU6dqPb=RHv8PHHt6FyuxAisDAHQ@mail.gmail.com>
 <464e5543-2f6c-6609-cf40-9208d2b8bc44@oracle.com>
Message-ID: <f30ec8e6-9dde-4083-b8ab-4fb1bead650f@oracle.com>

On 03/10/2018 16:03, Phil Race wrote:
> http://cr.openjdk.java.net/~tvaleev/webrev/8211300/r1/src/java.desktop/share/classes/javax/swing/tree/FixedHeightLayoutCache.java.udiff.html 
> 
> http://cr.openjdk.java.net/~tvaleev/webrev/8211300/r1/src/java.desktop/share/classes/javax/swing/tree/VariableHeightLayoutCache.java.udiff.html 
> 
> 
> Sergey, are you going to commit this, or am I ?

I can push it.

> 
> The changes in demos + accessibility are best handled under a different 
> bug id since
> this one is quite far along ..
> 
> -phil.
> 
> On 10/03/2018 03:06 AM, Tagir Valeev wrote:
>> Hello!
>>
>>> Given what Sergey has done, I don't need to repeat that work.
>>> I am now just looking for formatting anomalies, but there is a lot to
>>> look at.
>>> I should be able to OK this tomorrow and we can then commit it on your
>>> behalf.
>> Thanks, that would be great!
>>
>>> Have? you looked at the other client modules ? datatransfer, 
>>> accessibility,
>>> jdk.unsupported.desktop, or the client demos ?
>> No, I haven't. I was not aware that there are other client modules. I
>> assume that client demos are in src/demo/share directory, right?
>> I found no hits in datatransfer and jdk.unsupported.desktop, 4 files
>> in accessibility and 71 files in demos. Here's separate webrev for
>> these 75 files:
>> http://cr.openjdk.java.net/~tvaleev/patches/c_style_arrays_demos_accessibility/ 
>>
>> Should I post a separate JBS issue for this (or two issues) or it
>> could be incorporated within existing issue?
>> Should I post separate reviews for accessibility and demos or it's
>> fine to have them together?
>>
>>> If you are crazy (just an idea) then maybe even tests !
>>> But that latter one is a low priority.
>> Let's postpone tests. I'd like to move to some core modules like
>> java.base until my volunteering energy runs out :-)
>>
>>> ? > It appeared that compound declarations like `byte r[], g[], b[];`
>>> ? > are converted to `byte[] r;byte[] g; byte[] b;
>>>
>>> Seems like someone should fix their tool :-)
>> Yeah, this is what I'm thinking about (I'm IDEA developer). See, IDEA
>> processes every hit separately, and we have three independent hits
>> here. So when it processes r[] it doesn't know that I want to convert
>> others as well, thus it has to split the compound declaration into
>> `byte[] r;byte g[], b[];` (when formatting is active, they are placed
>> on separate lines, but I switched off the formatting to simplify the
>> changeset). The same is repeated for `g` and `b` independently and we
>> have unpleasant result. Probably we can fix this issuing single
>> warning per declaration and suggesting to fix the whole declaration or
>> nothing (it's unlikely that somebody would like to fix only some of
>> these arrays), but then the question is which source element should be
>> highlighted. Now we highlight three pairs of brackets in three
>> individual warnings, but if we have a single warning, we should
>> highlight something continuous. We may highlight the whole
>> declaration, but what if it also contains non-convertible things like
>> `byte r[], g, b[]`. Looks like a simple problem, but I don't see the
>> trivial solution. But ok, it's an off-topic :-)
>>
>> With best regards,
>> Tagir Valeev
>>
>>> -phil.
>>>
>>>
>>> On 10/1/18, 6:24 PM, Sergey Bylokhov wrote:
>>>> Looks fine to me.
>>>> I have checked the patch, have build the change and run some tests on
>>>> our supported platforms.
>>>>
>>>> On 30/09/2018 20:29, Tagir Valeev wrote:
>>>>> Hello!
>>>>>
>>>>> Please review JDK-8211300 [1] this change: [2]. Also it needs a
>>>>> sponsor as I have only JDK author status in OpenJDK Census [3].
>>>>>
>>>>> The discussion in core-libs-dev [4] shows that it's desired to get rid
>>>>> of old style array declarations like `int array[]` and massively
>>>>> convert them to `int[] array`. I volunteered to work on this. As Alan
>>>>> Bateman noted [5], java.desktop module is pushed to separate repo, so
>>>>> it would be better to process it separately, thus I'd like to start
>>>>> with it.
>>>>>
>>>>> The changeset was created in the following steps:
>>>>> * Import JDK sources to IntelliJ IDEA
>>>>> * Mark java.desktop/aix/classes, java.desktop/macosx/classes,
>>>>> java.desktop/unix/classes, java.desktop/solaris/classes,
>>>>> java.desktop/windows/classes and java.desktop/share/classes as source
>>>>> roots
>>>>> * Disable automatic formatting on the whole project
>>>>> * Run the inspection "C-style array declaration"
>>>>> * Apply the quick-fix massively
>>>>> * Perform regex replace over changed files only:
>>>>> Search: Copyright \(c\) (\d+), (\d+), Oracle and/or its affiliates.
>>>>> All rights reserved.
>>>>> Replace: Copyright \(c\) $1, 2018, Oracle and/or its affiliates. All
>>>>> rights reserved.
>>>>> * Perform regex replace over changed files only:
>>>>> Search: Copyright \(c\) (\d+), Oracle and/or its affiliates. All
>>>>> rights reserved.
>>>>> Replace: Copyright \(c\) $1, 2018, Oracle and/or its affiliates. All
>>>>> rights reserved.
>>>>> * It appeared that compound declarations like `byte r[], g[], b[];`
>>>>> are converted to `byte[] r;byte[] g; byte[] b;` which does not look
>>>>> nice while compilable. I found three such cases via simple regexp
>>>>> search in BMPImageReader#658, BMPImageWriter#325 and
>>>>> AreaAveragingScaleFilter#66 and fixed them manually.
>>>>>
>>>>> In total 339 files were changed with 1335 lines of array declaration
>>>>> updates and 310 lines of copyright updates. I reviewed the generated
>>>>> patch by eyes, but only partially, because it's too big. Also I
>>>>> performed some kind of simple sanity check using regexps:
>>>>>
>>>>> $ grep '^+[^+]' jdk.patch | grep -v 'Oracle and/or its affiliates. All
>>>>> rights reserved'|grep -v '\[\]'|wc
>>>>> ??????? 0?????? 0?????? 0
>>>>> (check that every updated line contains either copyright message or 
>>>>> [])
>>>>>
>>>>> With best regards,
>>>>> Tagir Valeev.
>>>>>
>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8211300
>>>>> [2] http://cr.openjdk.java.net/~tvaleev/webrev/8211300/r1/
>>>>> [3] http://openjdk.java.net/census#tvaleev
>>>>> [4]
>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055390.html 
>>>>>
>>>>> [5]
>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055759.html 
>>>>>
>>>>>
>>>>
> 


-- 
Best regards, Sergey.

From amaembo at gmail.com  Thu Oct  4 03:46:36 2018
From: amaembo at gmail.com (Tagir Valeev)
Date: Thu, 4 Oct 2018 10:46:36 +0700
Subject: [OpenJDK 2D-Dev] RFR: JDK-8211693 Convert C-style array
 declarations in client demos and jdk.accessibility
Message-ID: <CAE+3fjakLRkuZUNTaP7Mz69-mAT0VwjdGkwgdYkU+9brue58EQ@mail.gmail.com>

Please review and sponsor the conversion of C-style arrays in other
client modules: demos and jdk.accessibility (a left-over after
JDK-8211300):
http://cr.openjdk.java.net/~tvaleev/webrev/8211693/r1/
https://bugs.openjdk.java.net/browse/JDK-8211693

This patch is much smaller, only 75 files are affected (71 in demos
and 4 in accessibility). The procedure was the same as previously. I
manually fixed these two compound declarations:

1. Font2DTest.java:
-            String fileText, textLines[];
+            String fileText;
+            String[] textLines;

2. java2d/Intro.java
-            private Shape shapes[], txShapes[];
+            private Shape[] shapes, txShapes;

Everything else was nicely converted automatically. This time I
reviewed the whole patch by eyes and haven't noticed any formatting
issues.

Other two client modules java.datatransfer and jdk.unsupported.desktop
were also checked and no C-style array declarations were found there.

With best regards,
Tagir Valeev.

From mailto.woden at gmail.com  Thu Oct  4 05:54:58 2018
From: mailto.woden at gmail.com (Daniel Persson)
Date: Thu, 4 Oct 2018 07:54:58 +0200
Subject: [OpenJDK 2D-Dev] Rendering images from PDF files slower in
	OpenJDK
In-Reply-To: <CAKjRUT5U1=EqYNpM64Wr-GmX2WKnjC5VThOcnSNEgvQi2zg1ew@mail.gmail.com>
References: <CALLYd6TyN2Fc+vFOrg9e-RA+M67G56gJ8E1jn+1CnFYkz6cKZg@mail.gmail.com>
 <3584070c-9406-b7a2-2d68-b485a0c1fcdd@oracle.com>
 <CALLYd6SC2+uEm4kVCZ1cLVm9EiKVnejcU+PwcmzZ0inPYRH3EQ@mail.gmail.com>
 <5BABCDDD.5080403@oracle.com>
 <CAKjRUT7jb7tqAEpmkFbCrg=Vn29Q3NfcKZ5zm0JsFS0R59UocQ@mail.gmail.com>
 <CAKjRUT6qt1MkYcs+-3zE+yv0jrnRVt4_Fjcj=n=D+zZDgsiUKg@mail.gmail.com>
 <280e74f7-7ca1-8fc0-9912-412c0229658b@oracle.com>
 <CALLYd6QzQmvggNS7ajgkf2vsUc2zEFDnAN7z0ntZucPvOO475g@mail.gmail.com>
 <CAKjRUT4YQp+6d=z_RSQ2ufrRtwmVA-308LFxowoQ3ewuXSyJ8A@mail.gmail.com>
 <873cc9de-604f-8b11-a5ba-fcccf4337e81@oracle.com>
 <CAKjRUT5XqGdVO10UDJK7VuS5nEo_p0pDohxm=GiMqosdzA7Tgw@mail.gmail.com>
 <a281fd1e-2702-1de3-b4df-823fb3f6c2b2@oracle.com>
 <CAKjRUT5U1=EqYNpM64Wr-GmX2WKnjC5VThOcnSNEgvQi2zg1ew@mail.gmail.com>
Message-ID: <CALLYd6RPjJBss_eTnfAA6UomY=Eis0iu+Lj8Zp_7sO1LEKkQeA@mail.gmail.com>

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.laurent at 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.race at 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.race at 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
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181004/b80a9274/attachment-0001.html>

From bourges.laurent at gmail.com  Thu Oct  4 06:58:30 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Thu, 4 Oct 2018 08:58:30 +0200
Subject: [OpenJDK 2D-Dev] Rendering images from PDF files slower in
	OpenJDK
In-Reply-To: <CALLYd6RPjJBss_eTnfAA6UomY=Eis0iu+Lj8Zp_7sO1LEKkQeA@mail.gmail.com>
References: <CALLYd6TyN2Fc+vFOrg9e-RA+M67G56gJ8E1jn+1CnFYkz6cKZg@mail.gmail.com>
 <3584070c-9406-b7a2-2d68-b485a0c1fcdd@oracle.com>
 <CALLYd6SC2+uEm4kVCZ1cLVm9EiKVnejcU+PwcmzZ0inPYRH3EQ@mail.gmail.com>
 <5BABCDDD.5080403@oracle.com>
 <CAKjRUT7jb7tqAEpmkFbCrg=Vn29Q3NfcKZ5zm0JsFS0R59UocQ@mail.gmail.com>
 <CAKjRUT6qt1MkYcs+-3zE+yv0jrnRVt4_Fjcj=n=D+zZDgsiUKg@mail.gmail.com>
 <280e74f7-7ca1-8fc0-9912-412c0229658b@oracle.com>
 <CALLYd6QzQmvggNS7ajgkf2vsUc2zEFDnAN7z0ntZucPvOO475g@mail.gmail.com>
 <CAKjRUT4YQp+6d=z_RSQ2ufrRtwmVA-308LFxowoQ3ewuXSyJ8A@mail.gmail.com>
 <873cc9de-604f-8b11-a5ba-fcccf4337e81@oracle.com>
 <CAKjRUT5XqGdVO10UDJK7VuS5nEo_p0pDohxm=GiMqosdzA7Tgw@mail.gmail.com>
 <a281fd1e-2702-1de3-b4df-823fb3f6c2b2@oracle.com>
 <CAKjRUT5U1=EqYNpM64Wr-GmX2WKnjC5VThOcnSNEgvQi2zg1ew@mail.gmail.com>
 <CALLYd6RPjJBss_eTnfAA6UomY=Eis0iu+Lj8Zp_7sO1LEKkQeA@mail.gmail.com>
Message-ID: <CAKjRUT4BKY-5L=WVtcgNkTGHFERmdop5r9xZBe_aF8yQef2Stg@mail.gmail.com>

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.woden at 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.laurent at 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.race at 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.race at 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
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181004/de7467f5/attachment.html>

From philip.race at oracle.com  Thu Oct  4 18:02:42 2018
From: philip.race at oracle.com (Phil Race)
Date: Thu, 4 Oct 2018 11:02:42 -0700
Subject: [OpenJDK 2D-Dev] Rendering images from PDF files slower in
 OpenJDK
In-Reply-To: <CAKjRUT4BKY-5L=WVtcgNkTGHFERmdop5r9xZBe_aF8yQef2Stg@mail.gmail.com>
References: <CALLYd6TyN2Fc+vFOrg9e-RA+M67G56gJ8E1jn+1CnFYkz6cKZg@mail.gmail.com>
 <3584070c-9406-b7a2-2d68-b485a0c1fcdd@oracle.com>
 <CALLYd6SC2+uEm4kVCZ1cLVm9EiKVnejcU+PwcmzZ0inPYRH3EQ@mail.gmail.com>
 <5BABCDDD.5080403@oracle.com>
 <CAKjRUT7jb7tqAEpmkFbCrg=Vn29Q3NfcKZ5zm0JsFS0R59UocQ@mail.gmail.com>
 <CAKjRUT6qt1MkYcs+-3zE+yv0jrnRVt4_Fjcj=n=D+zZDgsiUKg@mail.gmail.com>
 <280e74f7-7ca1-8fc0-9912-412c0229658b@oracle.com>
 <CALLYd6QzQmvggNS7ajgkf2vsUc2zEFDnAN7z0ntZucPvOO475g@mail.gmail.com>
 <CAKjRUT4YQp+6d=z_RSQ2ufrRtwmVA-308LFxowoQ3ewuXSyJ8A@mail.gmail.com>
 <873cc9de-604f-8b11-a5ba-fcccf4337e81@oracle.com>
 <CAKjRUT5XqGdVO10UDJK7VuS5nEo_p0pDohxm=GiMqosdzA7Tgw@mail.gmail.com>
 <a281fd1e-2702-1de3-b4df-823fb3f6c2b2@oracle.com>
 <CAKjRUT5U1=EqYNpM64Wr-GmX2WKnjC5VThOcnSNEgvQi2zg1ew@mail.gmail.com>
 <CALLYd6RPjJBss_eTnfAA6UomY=Eis0iu+Lj8Zp_7sO1LEKkQeA@mail.gmail.com>
 <CAKjRUT4BKY-5L=WVtcgNkTGHFERmdop5r9xZBe_aF8yQef2Stg@mail.gmail.com>
Message-ID: <fbb24f35-44be-17e4-1b33-01b72faa328d@oracle.com>



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.woden at gmail.com 
> <mailto:mailto.woden at 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.laurent at gmail.com <mailto:bourges.laurent at 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.race at oracle.com <mailto:philip.race at 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.race at oracle.com <mailto:philip.race at 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
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181004/6a933bb4/attachment.html>

From bourges.laurent at gmail.com  Thu Oct  4 18:33:23 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Thu, 4 Oct 2018 20:33:23 +0200
Subject: [OpenJDK 2D-Dev] Rendering images from PDF files slower in
	OpenJDK
In-Reply-To: <fbb24f35-44be-17e4-1b33-01b72faa328d@oracle.com>
References: <CALLYd6TyN2Fc+vFOrg9e-RA+M67G56gJ8E1jn+1CnFYkz6cKZg@mail.gmail.com>
 <3584070c-9406-b7a2-2d68-b485a0c1fcdd@oracle.com>
 <CALLYd6SC2+uEm4kVCZ1cLVm9EiKVnejcU+PwcmzZ0inPYRH3EQ@mail.gmail.com>
 <5BABCDDD.5080403@oracle.com>
 <CAKjRUT7jb7tqAEpmkFbCrg=Vn29Q3NfcKZ5zm0JsFS0R59UocQ@mail.gmail.com>
 <CAKjRUT6qt1MkYcs+-3zE+yv0jrnRVt4_Fjcj=n=D+zZDgsiUKg@mail.gmail.com>
 <280e74f7-7ca1-8fc0-9912-412c0229658b@oracle.com>
 <CALLYd6QzQmvggNS7ajgkf2vsUc2zEFDnAN7z0ntZucPvOO475g@mail.gmail.com>
 <CAKjRUT4YQp+6d=z_RSQ2ufrRtwmVA-308LFxowoQ3ewuXSyJ8A@mail.gmail.com>
 <873cc9de-604f-8b11-a5ba-fcccf4337e81@oracle.com>
 <CAKjRUT5XqGdVO10UDJK7VuS5nEo_p0pDohxm=GiMqosdzA7Tgw@mail.gmail.com>
 <a281fd1e-2702-1de3-b4df-823fb3f6c2b2@oracle.com>
 <CAKjRUT5U1=EqYNpM64Wr-GmX2WKnjC5VThOcnSNEgvQi2zg1ew@mail.gmail.com>
 <CALLYd6RPjJBss_eTnfAA6UomY=Eis0iu+Lj8Zp_7sO1LEKkQeA@mail.gmail.com>
 <CAKjRUT4BKY-5L=WVtcgNkTGHFERmdop5r9xZBe_aF8yQef2Stg@mail.gmail.com>
 <fbb24f35-44be-17e4-1b33-01b72faa328d@oracle.com>
Message-ID: <CAKjRUT4x4vxHLH+XHfc5Lh7u5FQ0eexauGPcwS8p3tLdymC9wA@mail.gmail.com>

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.race at 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.woden at 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.laurent at 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.race at 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.race at 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
>>>>>
>>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181004/8805c02b/attachment-0001.html>

From philip.race at oracle.com  Thu Oct  4 21:24:49 2018
From: philip.race at oracle.com (Philip Race)
Date: Thu, 04 Oct 2018 14:24:49 -0700
Subject: [OpenJDK 2D-Dev] Rendering images from PDF files slower in
	OpenJDK
In-Reply-To: <CAKjRUT4x4vxHLH+XHfc5Lh7u5FQ0eexauGPcwS8p3tLdymC9wA@mail.gmail.com>
References: <CALLYd6TyN2Fc+vFOrg9e-RA+M67G56gJ8E1jn+1CnFYkz6cKZg@mail.gmail.com>
 <5BABCDDD.5080403@oracle.com>
 <CAKjRUT7jb7tqAEpmkFbCrg=Vn29Q3NfcKZ5zm0JsFS0R59UocQ@mail.gmail.com>
 <CAKjRUT6qt1MkYcs+-3zE+yv0jrnRVt4_Fjcj=n=D+zZDgsiUKg@mail.gmail.com>
 <280e74f7-7ca1-8fc0-9912-412c0229658b@oracle.com>
 <CALLYd6QzQmvggNS7ajgkf2vsUc2zEFDnAN7z0ntZucPvOO475g@mail.gmail.com>
 <CAKjRUT4YQp+6d=z_RSQ2ufrRtwmVA-308LFxowoQ3ewuXSyJ8A@mail.gmail.com>
 <873cc9de-604f-8b11-a5ba-fcccf4337e81@oracle.com>
 <CAKjRUT5XqGdVO10UDJK7VuS5nEo_p0pDohxm=GiMqosdzA7Tgw@mail.gmail.com>
 <a281fd1e-2702-1de3-b4df-823fb3f6c2b2@oracle.com>
 <CAKjRUT5U1=EqYNpM64Wr-GmX2WKnjC5VThOcnSNEgvQi2zg1ew@mail.gmail.com>
 <CALLYd6RPjJBss_eTnfAA6UomY=Eis0iu+Lj8Zp_7sO1LEKkQeA@mail.gmail.com>
 <CAKjRUT4BKY-5L=WVtcgNkTGHFERmdop5r9xZBe_aF8yQef2Stg@mail.gmail.com>
 <fbb24f35-44be-17e4-1b33-01b72faa328d@oracle.com>
 <CAKjRUT4x4vxHLH+XHfc5Lh7u5FQ0eexauGPcwS8p3tLdymC9wA@mail.gmail.com>
Message-ID: <5BB68521.7040708@oracle.com>

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.race at oracle.com 
> <mailto:philip.race at 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.woden at gmail.com <mailto:mailto.woden at 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.laurent at gmail.com
>>         <mailto:bourges.laurent at 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.race at oracle.com <mailto:philip.race at 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.race at oracle.com
>>>                 <mailto:philip.race at 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
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181004/db0d735c/attachment-0001.html>

From philip.race at oracle.com  Thu Oct  4 23:00:26 2018
From: philip.race at oracle.com (Philip Race)
Date: Thu, 04 Oct 2018 16:00:26 -0700
Subject: [OpenJDK 2D-Dev] Rendering images from PDF files slower in
	OpenJDK
In-Reply-To: <5BB68521.7040708@oracle.com>
References: <CALLYd6TyN2Fc+vFOrg9e-RA+M67G56gJ8E1jn+1CnFYkz6cKZg@mail.gmail.com>
 <5BABCDDD.5080403@oracle.com>
 <CAKjRUT7jb7tqAEpmkFbCrg=Vn29Q3NfcKZ5zm0JsFS0R59UocQ@mail.gmail.com>
 <CAKjRUT6qt1MkYcs+-3zE+yv0jrnRVt4_Fjcj=n=D+zZDgsiUKg@mail.gmail.com>
 <280e74f7-7ca1-8fc0-9912-412c0229658b@oracle.com>
 <CALLYd6QzQmvggNS7ajgkf2vsUc2zEFDnAN7z0ntZucPvOO475g@mail.gmail.com>
 <CAKjRUT4YQp+6d=z_RSQ2ufrRtwmVA-308LFxowoQ3ewuXSyJ8A@mail.gmail.com>
 <873cc9de-604f-8b11-a5ba-fcccf4337e81@oracle.com>
 <CAKjRUT5XqGdVO10UDJK7VuS5nEo_p0pDohxm=GiMqosdzA7Tgw@mail.gmail.com>
 <a281fd1e-2702-1de3-b4df-823fb3f6c2b2@oracle.com>
 <CAKjRUT5U1=EqYNpM64Wr-GmX2WKnjC5VThOcnSNEgvQi2zg1ew@mail.gmail.com>
 <CALLYd6RPjJBss_eTnfAA6UomY=Eis0iu+Lj8Zp_7sO1LEKkQeA@mail.gmail.com>
 <CAKjRUT4BKY-5L=WVtcgNkTGHFERmdop5r9xZBe_aF8yQef2Stg@mail.gmail.com>
 <fbb24f35-44be-17e4-1b33-01b72faa328d@oracle.com>
 <CAKjRUT4x4vxHLH+XHfc5Lh7u5FQ0eexauGPcwS8p3tLdymC9wA@mail.gmail.com>
 <5BB68521.7040708@oracle.com>
Message-ID: <5BB69B8A.3040106@oracle.com>

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.race at oracle.com 
>> <mailto:philip.race at 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.woden at gmail.com <mailto:mailto.woden at 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.laurent at gmail.com
>>>         <mailto:bourges.laurent at 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.race at oracle.com <mailto:philip.race at 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.race at oracle.com
>>>>                 <mailto:philip.race at 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
>>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181004/28132518/attachment-0001.html>

From bourges.laurent at gmail.com  Fri Oct  5 04:53:56 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Fri, 5 Oct 2018 06:53:56 +0200
Subject: [OpenJDK 2D-Dev] Rendering images from PDF files slower in
	OpenJDK
In-Reply-To: <5BB69B8A.3040106@oracle.com>
References: <CALLYd6TyN2Fc+vFOrg9e-RA+M67G56gJ8E1jn+1CnFYkz6cKZg@mail.gmail.com>
 <5BABCDDD.5080403@oracle.com>
 <CAKjRUT7jb7tqAEpmkFbCrg=Vn29Q3NfcKZ5zm0JsFS0R59UocQ@mail.gmail.com>
 <CAKjRUT6qt1MkYcs+-3zE+yv0jrnRVt4_Fjcj=n=D+zZDgsiUKg@mail.gmail.com>
 <280e74f7-7ca1-8fc0-9912-412c0229658b@oracle.com>
 <CALLYd6QzQmvggNS7ajgkf2vsUc2zEFDnAN7z0ntZucPvOO475g@mail.gmail.com>
 <CAKjRUT4YQp+6d=z_RSQ2ufrRtwmVA-308LFxowoQ3ewuXSyJ8A@mail.gmail.com>
 <873cc9de-604f-8b11-a5ba-fcccf4337e81@oracle.com>
 <CAKjRUT5XqGdVO10UDJK7VuS5nEo_p0pDohxm=GiMqosdzA7Tgw@mail.gmail.com>
 <a281fd1e-2702-1de3-b4df-823fb3f6c2b2@oracle.com>
 <CAKjRUT5U1=EqYNpM64Wr-GmX2WKnjC5VThOcnSNEgvQi2zg1ew@mail.gmail.com>
 <CALLYd6RPjJBss_eTnfAA6UomY=Eis0iu+Lj8Zp_7sO1LEKkQeA@mail.gmail.com>
 <CAKjRUT4BKY-5L=WVtcgNkTGHFERmdop5r9xZBe_aF8yQef2Stg@mail.gmail.com>
 <fbb24f35-44be-17e4-1b33-01b72faa328d@oracle.com>
 <CAKjRUT4x4vxHLH+XHfc5Lh7u5FQ0eexauGPcwS8p3tLdymC9wA@mail.gmail.com>
 <5BB68521.7040708@oracle.com> <5BB69B8A.3040106@oracle.com>
Message-ID: <CAKjRUT68rT=RaMqCau3O1d86eFDkgg1KZLMXhyXowubXcdt9uw@mail.gmail.com>

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.race at 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.race at 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.woden at 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.laurent at 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.race at 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.race at 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
>>>>>>
>>>>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181005/07b3021b/attachment-0001.html>

From mailto.woden at gmail.com  Fri Oct  5 05:22:55 2018
From: mailto.woden at gmail.com (Daniel Persson)
Date: Fri, 5 Oct 2018 07:22:55 +0200
Subject: [OpenJDK 2D-Dev] Rendering images from PDF files slower in
	OpenJDK
In-Reply-To: <CAKjRUT68rT=RaMqCau3O1d86eFDkgg1KZLMXhyXowubXcdt9uw@mail.gmail.com>
References: <CALLYd6TyN2Fc+vFOrg9e-RA+M67G56gJ8E1jn+1CnFYkz6cKZg@mail.gmail.com>
 <5BABCDDD.5080403@oracle.com>
 <CAKjRUT7jb7tqAEpmkFbCrg=Vn29Q3NfcKZ5zm0JsFS0R59UocQ@mail.gmail.com>
 <CAKjRUT6qt1MkYcs+-3zE+yv0jrnRVt4_Fjcj=n=D+zZDgsiUKg@mail.gmail.com>
 <280e74f7-7ca1-8fc0-9912-412c0229658b@oracle.com>
 <CALLYd6QzQmvggNS7ajgkf2vsUc2zEFDnAN7z0ntZucPvOO475g@mail.gmail.com>
 <CAKjRUT4YQp+6d=z_RSQ2ufrRtwmVA-308LFxowoQ3ewuXSyJ8A@mail.gmail.com>
 <873cc9de-604f-8b11-a5ba-fcccf4337e81@oracle.com>
 <CAKjRUT5XqGdVO10UDJK7VuS5nEo_p0pDohxm=GiMqosdzA7Tgw@mail.gmail.com>
 <a281fd1e-2702-1de3-b4df-823fb3f6c2b2@oracle.com>
 <CAKjRUT5U1=EqYNpM64Wr-GmX2WKnjC5VThOcnSNEgvQi2zg1ew@mail.gmail.com>
 <CALLYd6RPjJBss_eTnfAA6UomY=Eis0iu+Lj8Zp_7sO1LEKkQeA@mail.gmail.com>
 <CAKjRUT4BKY-5L=WVtcgNkTGHFERmdop5r9xZBe_aF8yQef2Stg@mail.gmail.com>
 <fbb24f35-44be-17e4-1b33-01b72faa328d@oracle.com>
 <CAKjRUT4x4vxHLH+XHfc5Lh7u5FQ0eexauGPcwS8p3tLdymC9wA@mail.gmail.com>
 <5BB68521.7040708@oracle.com> <5BB69B8A.3040106@oracle.com>
 <CAKjRUT68rT=RaMqCau3O1d86eFDkgg1KZLMXhyXowubXcdt9uw@mail.gmail.com>
Message-ID: <CALLYd6TgJxnisWrtKWFAn58nGe6_DD4vdM-iByeGwNTqSL6dnA@mail.gmail.com>

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 forward have KcmsServiceProvider bundled?
Does this provider make a worse result on the image?

Best regards
Daniel




On Fri, Oct 5, 2018 at 6:55 AM Laurent Bourg?s <bourges.laurent at gmail.com>
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
>
> That's all folks !
>
> Le ven. 5 oct. 2018 ? 01:00, Philip Race <philip.race at 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.race at 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.woden at 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.laurent at 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.race at 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.race at 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
>>>>>>>
>>>>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181005/bccbbc3f/attachment-0001.html>

From philip.race at oracle.com  Fri Oct  5 05:21:53 2018
From: philip.race at oracle.com (Philip Race)
Date: Thu, 04 Oct 2018 22:21:53 -0700
Subject: [OpenJDK 2D-Dev] Rendering images from PDF files slower in
	OpenJDK
In-Reply-To: <CAKjRUT68rT=RaMqCau3O1d86eFDkgg1KZLMXhyXowubXcdt9uw@mail.gmail.com>
References: <CALLYd6TyN2Fc+vFOrg9e-RA+M67G56gJ8E1jn+1CnFYkz6cKZg@mail.gmail.com>
 <CAKjRUT6qt1MkYcs+-3zE+yv0jrnRVt4_Fjcj=n=D+zZDgsiUKg@mail.gmail.com>
 <280e74f7-7ca1-8fc0-9912-412c0229658b@oracle.com>
 <CALLYd6QzQmvggNS7ajgkf2vsUc2zEFDnAN7z0ntZucPvOO475g@mail.gmail.com>
 <CAKjRUT4YQp+6d=z_RSQ2ufrRtwmVA-308LFxowoQ3ewuXSyJ8A@mail.gmail.com>
 <873cc9de-604f-8b11-a5ba-fcccf4337e81@oracle.com>
 <CAKjRUT5XqGdVO10UDJK7VuS5nEo_p0pDohxm=GiMqosdzA7Tgw@mail.gmail.com>
 <a281fd1e-2702-1de3-b4df-823fb3f6c2b2@oracle.com>
 <CAKjRUT5U1=EqYNpM64Wr-GmX2WKnjC5VThOcnSNEgvQi2zg1ew@mail.gmail.com>
 <CALLYd6RPjJBss_eTnfAA6UomY=Eis0iu+Lj8Zp_7sO1LEKkQeA@mail.gmail.com>
 <CAKjRUT4BKY-5L=WVtcgNkTGHFERmdop5r9xZBe_aF8yQef2Stg@mail.gmail.com>
 <fbb24f35-44be-17e4-1b33-01b72faa328d@oracle.com>
 <CAKjRUT4x4vxHLH+XHfc5Lh7u5FQ0eexauGPcwS8p3tLdymC9wA@mail.gmail.com>
 <5BB68521.7040708@oracle.com> <5BB69B8A.3040106@oracle.com>
 <CAKjRUT68rT=RaMqCau3O1d86eFDkgg1KZLMXhyXowubXcdt9uw@mail.gmail.com>
Message-ID: <5BB6F4F1.9090400@oracle.com>

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.race at oracle.com 
> <mailto:philip.race at 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.race at oracle.com
>>>     <mailto:philip.race at 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.woden at gmail.com <mailto:mailto.woden at 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.laurent at gmail.com
>>>>             <mailto:bourges.laurent at 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.race at oracle.com
>>>>                 <mailto:philip.race at 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.race at oracle.com
>>>>>                     <mailto:philip.race at 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
>>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181004/17cd585c/attachment-0001.html>

From philip.race at oracle.com  Fri Oct  5 05:27:43 2018
From: philip.race at oracle.com (Philip Race)
Date: Thu, 04 Oct 2018 22:27:43 -0700
Subject: [OpenJDK 2D-Dev] Rendering images from PDF files slower in
	OpenJDK
In-Reply-To: <CALLYd6TgJxnisWrtKWFAn58nGe6_DD4vdM-iByeGwNTqSL6dnA@mail.gmail.com>
References: <CALLYd6TyN2Fc+vFOrg9e-RA+M67G56gJ8E1jn+1CnFYkz6cKZg@mail.gmail.com>
 <280e74f7-7ca1-8fc0-9912-412c0229658b@oracle.com>
 <CALLYd6QzQmvggNS7ajgkf2vsUc2zEFDnAN7z0ntZucPvOO475g@mail.gmail.com>
 <CAKjRUT4YQp+6d=z_RSQ2ufrRtwmVA-308LFxowoQ3ewuXSyJ8A@mail.gmail.com>
 <873cc9de-604f-8b11-a5ba-fcccf4337e81@oracle.com>
 <CAKjRUT5XqGdVO10UDJK7VuS5nEo_p0pDohxm=GiMqosdzA7Tgw@mail.gmail.com>
 <a281fd1e-2702-1de3-b4df-823fb3f6c2b2@oracle.com>
 <CAKjRUT5U1=EqYNpM64Wr-GmX2WKnjC5VThOcnSNEgvQi2zg1ew@mail.gmail.com>
 <CALLYd6RPjJBss_eTnfAA6UomY=Eis0iu+Lj8Zp_7sO1LEKkQeA@mail.gmail.com>
 <CAKjRUT4BKY-5L=WVtcgNkTGHFERmdop5r9xZBe_aF8yQef2Stg@mail.gmail.com>
 <fbb24f35-44be-17e4-1b33-01b72faa328d@oracle.com>
 <CAKjRUT4x4vxHLH+XHfc5Lh7u5FQ0eexauGPcwS8p3tLdymC9wA@mail.gmail.com>
 <5BB68521.7040708@oracle.com> <5BB69B8A.3040106@oracle.com>
 <CAKjRUT68rT=RaMqCau3O1d86eFDkgg1KZLMXhyXowubXcdt9uw@mail.gmail.com>
 <CALLYd6TgJxnisWrtKWFAn58nGe6_DD4vdM-iByeGwNTqSL6dnA@mail.gmail.com>
Message-ID: <5BB6F64F.2080303@oracle.com>



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

I tried playing with different image data but I didn't see a sensitivity 
to that.
Maybe I needed to try something more complex.
>
> So why don't OpenJDK 9 and forward have KcmsServiceProvider bundled?
> Does this provider make a worse result on the image?
>
It is not open source. It cannot be part of OpenJDK. Ever.
And see my other email for the other reasons.
So there is no quick or easy solution.

FWIW the #1 reason I left KCMS in Oracle 8 and even 9 was because of the 
MT performance
issue, but as we now converge Oracle JDK & OpenJDK that was a 
non-starter and it was
removed along with other closed source components.

-phil.

> Best regards
> Daniel
>
>
>
>
> On Fri, Oct 5, 2018 at 6:55 AM Laurent Bourg?s 
> <bourges.laurent at gmail.com <mailto:bourges.laurent at gmail.com>> 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.race at oracle.com
>     <mailto:philip.race at 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.race at oracle.com <mailto:philip.race at 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.woden at gmail.com
>>>>             <mailto:mailto.woden at 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.laurent at gmail.com
>>>>                 <mailto:bourges.laurent at 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.race at oracle.com
>>>>                     <mailto:philip.race at 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.race at oracle.com
>>>>>                         <mailto:philip.race at 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
>>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181004/d6ac74cb/attachment-0001.html>

From mailto.woden at gmail.com  Fri Oct  5 05:47:37 2018
From: mailto.woden at gmail.com (Daniel Persson)
Date: Fri, 5 Oct 2018 07:47:37 +0200
Subject: [OpenJDK 2D-Dev] Rendering images from PDF files slower in
	OpenJDK
In-Reply-To: <5BB6F64F.2080303@oracle.com>
References: <CALLYd6TyN2Fc+vFOrg9e-RA+M67G56gJ8E1jn+1CnFYkz6cKZg@mail.gmail.com>
 <280e74f7-7ca1-8fc0-9912-412c0229658b@oracle.com>
 <CALLYd6QzQmvggNS7ajgkf2vsUc2zEFDnAN7z0ntZucPvOO475g@mail.gmail.com>
 <CAKjRUT4YQp+6d=z_RSQ2ufrRtwmVA-308LFxowoQ3ewuXSyJ8A@mail.gmail.com>
 <873cc9de-604f-8b11-a5ba-fcccf4337e81@oracle.com>
 <CAKjRUT5XqGdVO10UDJK7VuS5nEo_p0pDohxm=GiMqosdzA7Tgw@mail.gmail.com>
 <a281fd1e-2702-1de3-b4df-823fb3f6c2b2@oracle.com>
 <CAKjRUT5U1=EqYNpM64Wr-GmX2WKnjC5VThOcnSNEgvQi2zg1ew@mail.gmail.com>
 <CALLYd6RPjJBss_eTnfAA6UomY=Eis0iu+Lj8Zp_7sO1LEKkQeA@mail.gmail.com>
 <CAKjRUT4BKY-5L=WVtcgNkTGHFERmdop5r9xZBe_aF8yQef2Stg@mail.gmail.com>
 <fbb24f35-44be-17e4-1b33-01b72faa328d@oracle.com>
 <CAKjRUT4x4vxHLH+XHfc5Lh7u5FQ0eexauGPcwS8p3tLdymC9wA@mail.gmail.com>
 <5BB68521.7040708@oracle.com> <5BB69B8A.3040106@oracle.com>
 <CAKjRUT68rT=RaMqCau3O1d86eFDkgg1KZLMXhyXowubXcdt9uw@mail.gmail.com>
 <CALLYd6TgJxnisWrtKWFAn58nGe6_DD4vdM-iByeGwNTqSL6dnA@mail.gmail.com>
 <5BB6F64F.2080303@oracle.com>
Message-ID: <CALLYd6TigE9vg9N8EkwfosyDOgwh3va++ZVmOJ5w67PrfJMMzQ@mail.gmail.com>

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 AM Philip Race <philip.race at oracle.com> wrote:

>
>
> 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 seconds
> difference.
>
>
> I tried playing with different image data but I didn't see a sensitivity
> to that.
> Maybe I needed to try something more complex.
>
>
> So why don't OpenJDK 9 and forward have KcmsServiceProvider bundled?
> Does this provider make a worse result on the image?
>
> It is not open source. It cannot be part of OpenJDK. Ever.
> And see my other email for the other reasons.
> So there is no quick or easy solution.
>
> FWIW the #1 reason I left KCMS in Oracle 8 and even 9 was because of the
> MT performance
> issue, but as we now converge Oracle JDK & OpenJDK that was a non-starter
> and it was
> removed along with other closed source components.
>
> -phil.
>
> Best regards
> Daniel
>
>
>
>
> On Fri, Oct 5, 2018 at 6:55 AM Laurent Bourg?s <bourges.laurent at gmail.com>
> 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
>>
>> That's all folks !
>>
>> Le ven. 5 oct. 2018 ? 01:00, Philip Race <philip.race at 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.race at 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.woden at 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.laurent at 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.race at 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.race at 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
>>>>>>>>
>>>>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181005/e5da67d6/attachment-0001.html>

From philip.race at oracle.com  Fri Oct  5 06:06:02 2018
From: philip.race at oracle.com (Philip Race)
Date: Thu, 04 Oct 2018 23:06:02 -0700
Subject: [OpenJDK 2D-Dev] Rendering images from PDF files slower in
	OpenJDK
In-Reply-To: <CALLYd6TigE9vg9N8EkwfosyDOgwh3va++ZVmOJ5w67PrfJMMzQ@mail.gmail.com>
References: <CALLYd6TyN2Fc+vFOrg9e-RA+M67G56gJ8E1jn+1CnFYkz6cKZg@mail.gmail.com>
 <CAKjRUT4YQp+6d=z_RSQ2ufrRtwmVA-308LFxowoQ3ewuXSyJ8A@mail.gmail.com>
 <873cc9de-604f-8b11-a5ba-fcccf4337e81@oracle.com>
 <CAKjRUT5XqGdVO10UDJK7VuS5nEo_p0pDohxm=GiMqosdzA7Tgw@mail.gmail.com>
 <a281fd1e-2702-1de3-b4df-823fb3f6c2b2@oracle.com>
 <CAKjRUT5U1=EqYNpM64Wr-GmX2WKnjC5VThOcnSNEgvQi2zg1ew@mail.gmail.com>
 <CALLYd6RPjJBss_eTnfAA6UomY=Eis0iu+Lj8Zp_7sO1LEKkQeA@mail.gmail.com>
 <CAKjRUT4BKY-5L=WVtcgNkTGHFERmdop5r9xZBe_aF8yQef2Stg@mail.gmail.com>
 <fbb24f35-44be-17e4-1b33-01b72faa328d@oracle.com>
 <CAKjRUT4x4vxHLH+XHfc5Lh7u5FQ0eexauGPcwS8p3tLdymC9wA@mail.gmail.com>
 <5BB68521.7040708@oracle.com> <5BB69B8A.3040106@oracle.com>
 <CAKjRUT68rT=RaMqCau3O1d86eFDkgg1KZLMXhyXowubXcdt9uw@mail.gmail.com>
 <CALLYd6TgJxnisWrtKWFAn58nGe6_DD4vdM-iByeGwNTqSL6dnA@mail.gmail.com>
 <5BB6F64F.2080303@oracle.com>
 <CALLYd6TigE9vg9N8EkwfosyDOgwh3va++ZVmOJ5w67PrfJMMzQ@mail.gmail.com>
Message-ID: <5BB6FF4A.3090105@oracle.com>

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 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 AM Philip Race <philip.race at oracle.com 
> <mailto:philip.race at oracle.com>> wrote:
>
>
>
>     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
>>     seconds difference.
>
>     I tried playing with different image data but I didn't see a
>     sensitivity to that.
>     Maybe I needed to try something more complex.
>>
>>     So why don't OpenJDK 9 and forward have KcmsServiceProvider bundled?
>>     Does this provider make a worse result on the image?
>>
>     It is not open source. It cannot be part of OpenJDK. Ever.
>     And see my other email for the other reasons.
>     So there is no quick or easy solution.
>
>     FWIW the #1 reason I left KCMS in Oracle 8 and even 9 was because
>     of the MT performance
>     issue, but as we now converge Oracle JDK & OpenJDK that was a
>     non-starter and it was
>     removed along with other closed source components.
>
>     -phil.
>
>>     Best regards
>>     Daniel
>>
>>
>>
>>
>>     On Fri, Oct 5, 2018 at 6:55 AM Laurent Bourg?s
>>     <bourges.laurent at gmail.com <mailto:bourges.laurent at gmail.com>> 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.race at oracle.com <mailto:philip.race at 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.race at oracle.com
>>>>             <mailto:philip.race at 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.woden at gmail.com
>>>>>                 <mailto:mailto.woden at 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.laurent at gmail.com
>>>>>                     <mailto:bourges.laurent at 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.race at oracle.com
>>>>>                         <mailto:philip.race at 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.race at oracle.com
>>>>>>                             <mailto:philip.race at 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
>>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181004/c10b3f34/attachment-0001.html>

From bourges.laurent at gmail.com  Fri Oct  5 06:45:19 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Fri, 5 Oct 2018 08:45:19 +0200
Subject: [OpenJDK 2D-Dev] Rendering images from PDF files slower in
	OpenJDK
In-Reply-To: <5BB6FF4A.3090105@oracle.com>
References: <CALLYd6TyN2Fc+vFOrg9e-RA+M67G56gJ8E1jn+1CnFYkz6cKZg@mail.gmail.com>
 <CAKjRUT4YQp+6d=z_RSQ2ufrRtwmVA-308LFxowoQ3ewuXSyJ8A@mail.gmail.com>
 <873cc9de-604f-8b11-a5ba-fcccf4337e81@oracle.com>
 <CAKjRUT5XqGdVO10UDJK7VuS5nEo_p0pDohxm=GiMqosdzA7Tgw@mail.gmail.com>
 <a281fd1e-2702-1de3-b4df-823fb3f6c2b2@oracle.com>
 <CAKjRUT5U1=EqYNpM64Wr-GmX2WKnjC5VThOcnSNEgvQi2zg1ew@mail.gmail.com>
 <CALLYd6RPjJBss_eTnfAA6UomY=Eis0iu+Lj8Zp_7sO1LEKkQeA@mail.gmail.com>
 <CAKjRUT4BKY-5L=WVtcgNkTGHFERmdop5r9xZBe_aF8yQef2Stg@mail.gmail.com>
 <fbb24f35-44be-17e4-1b33-01b72faa328d@oracle.com>
 <CAKjRUT4x4vxHLH+XHfc5Lh7u5FQ0eexauGPcwS8p3tLdymC9wA@mail.gmail.com>
 <5BB68521.7040708@oracle.com> <5BB69B8A.3040106@oracle.com>
 <CAKjRUT68rT=RaMqCau3O1d86eFDkgg1KZLMXhyXowubXcdt9uw@mail.gmail.com>
 <CALLYd6TgJxnisWrtKWFAn58nGe6_DD4vdM-iByeGwNTqSL6dnA@mail.gmail.com>
 <5BB6F64F.2080303@oracle.com>
 <CALLYd6TigE9vg9N8EkwfosyDOgwh3va++ZVmOJ5w67PrfJMMzQ@mail.gmail.com>
 <5BB6FF4A.3090105@oracle.com>
Message-ID: <CAKjRUT7ALdjKA5ZvdO8LV3_cGAOTBRtjZu7xQ9zcccPfPdBb8w@mail.gmail.com>

Phil,

Le ven. 5 oct. 2018 ? 08:06, Philip Race <philip.race at oracle.com> 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 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.
I would not make MT in lcms as it can affect MT in java.
Maybe PDFImage could convert tiles instead of the all image ?

Anyway I will publish my lknux perf report showing time spent in kcms /
lcms asap.

PS: I tested OpenJDK8 and perf is on par with OpenJDK9.

Laurent



> On 10/4/18, 10:47 PM, Daniel Persson wrote:
>
> 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 AM Philip Race <philip.race at oracle.com> wrote:
>
>>
>>
>> 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 seconds
>> difference.
>>
>>
>> I tried playing with different image data but I didn't see a sensitivity
>> to that.
>> Maybe I needed to try something more complex.
>>
>>
>> So why don't OpenJDK 9 and forward have KcmsServiceProvider bundled?
>> Does this provider make a worse result on the image?
>>
>> It is not open source. It cannot be part of OpenJDK. Ever.
>> And see my other email for the other reasons.
>> So there is no quick or easy solution.
>>
>> FWIW the #1 reason I left KCMS in Oracle 8 and even 9 was because of the
>> MT performance
>> issue, but as we now converge Oracle JDK & OpenJDK that was a non-starter
>> and it was
>> removed along with other closed source components.
>>
>> -phil.
>>
>> Best regards
>> Daniel
>>
>>
>>
>>
>> On Fri, Oct 5, 2018 at 6:55 AM Laurent Bourg?s <bourges.laurent at gmail.com>
>> 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
>>>
>>> That's all folks !
>>>
>>> Le ven. 5 oct. 2018 ? 01:00, Philip Race <philip.race at 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.race at 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.woden at 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.laurent at 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.race at 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.race at 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
>>>>>>>>>
>>>>>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181005/96b910a4/attachment-0001.html>

From Sergey.Bylokhov at oracle.com  Sat Oct  6 05:34:20 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 5 Oct 2018 22:34:20 -0700
Subject: [OpenJDK 2D-Dev] RFR: JDK-8211693 Convert C-style array
 declarations in client demos and jdk.accessibility
In-Reply-To: <CAE+3fjakLRkuZUNTaP7Mz69-mAT0VwjdGkwgdYkU+9brue58EQ@mail.gmail.com>
References: <CAE+3fjakLRkuZUNTaP7Mz69-mAT0VwjdGkwgdYkU+9brue58EQ@mail.gmail.com>
Message-ID: <9279220e-ebde-d9e3-1f47-af536b8ed932@oracle.com>

Looks fine.
I there are no objections I'll push the fix on Monday.

On 03/10/2018 20:46, Tagir Valeev wrote:
> Please review and sponsor the conversion of C-style arrays in other
> client modules: demos and jdk.accessibility (a left-over after
> JDK-8211300):
> http://cr.openjdk.java.net/~tvaleev/webrev/8211693/r1/
> https://bugs.openjdk.java.net/browse/JDK-8211693
> 
> This patch is much smaller, only 75 files are affected (71 in demos
> and 4 in accessibility). The procedure was the same as previously. I
> manually fixed these two compound declarations:
> 
> 1. Font2DTest.java:
> -            String fileText, textLines[];
> +            String fileText;
> +            String[] textLines;
> 
> 2. java2d/Intro.java
> -            private Shape shapes[], txShapes[];
> +            private Shape[] shapes, txShapes;
> 
> Everything else was nicely converted automatically. This time I
> reviewed the whole patch by eyes and haven't noticed any formatting
> issues.
> 
> Other two client modules java.datatransfer and jdk.unsupported.desktop
> were also checked and no C-style array declarations were found there.
> 
> With best regards,
> Tagir Valeev.
> 


-- 
Best regards, Sergey.

From john at status6.com  Mon Oct  8 20:23:23 2018
From: john at status6.com (John Neffenger)
Date: Mon, 8 Oct 2018 13:23:23 -0700
Subject: [OpenJDK 2D-Dev] Setting the FreeType LCD filter
Message-ID: <f5ef2fa9-52bf-9799-a41f-134bce17276b@status6.com>

Now that we fixed a font problem in JavaFX [1], let's fix the same 
problem in Java. I would like your feedback on the Request for 
Enhancement described below:

OpenJDK FreeType Font Fix
https://github.com/jgneff/openjdk-freetype

Thank you,
John

[1] https://github.com/javafxports/openjdk-jfx/issues/229

From peterhull90 at gmail.com  Tue Oct  9 13:27:46 2018
From: peterhull90 at gmail.com (Peter Hull)
Date: Tue, 9 Oct 2018 14:27:46 +0100
Subject: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11
Message-ID: <CAK9Gx1fx=w29r1BSCYwBsxqe6SMKTMpQPj30xb0-5F+0nsudMg@mail.gmail.com>

I posted this message first on Java Discuss and was asked to file a Java
bug. It was also suggested I post it here for discussion.

I've recently started using Java 11 and noticed that drawPolyline is
much slower on my PC than it was on Java 8.
Example, simplified code:
    @Override
    protected void paintComponent(Graphics g) {
        super.paintComponent(g);
        Graphics2D graphics = (Graphics2D) g;
        long starttime = System.nanoTime();
        graphics.drawPolyline(xs, ys, xs.length);
        long endtime = System.nanoTime();
        Logger.getLogger(this.getClass().getName()).log(Level.INFO,
"Paint Time: {0}s", (double)(endtime-starttime) / 1.0e9);
    }
where xs[] and ys[] are large (65536 points) integer arrays. On Java 8 I
get a paint time of 0.025s and on Java 11 it is 25s, i.e. factor of 1000.

This may be related to JEP263 (HiDPI)

I've got a recent Core i7 processor with Intel graphics, running Windows 10.

With VisualVM I can see that all the time goes in drawPolyline, I can't get
any more detail than that.

I have done some experimentation with RenderingHints but nothing makes the
JDK11 go as fast as JDK8.

Is there anything else I can try to either improve matters or to provide a
clearer idea of why there is such a difference?

I have a self-contained NetBeans project if anyone wants to try to see they
can reproduce this.
https://github.com/pedro-w/PolylineTest.git

Thanks,
Peter


Versions:
openjdk version "11" 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11+28)
OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)

openjdk version "1.8.0-adoptopenjdk"
OpenJDK Runtime Environment (build 1.8.0-adoptopenjdk-_2018_05_19_00_59-b00)
OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181009/0ba0078e/attachment.html>

From bourges.laurent at gmail.com  Tue Oct  9 14:52:27 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Tue, 9 Oct 2018 16:52:27 +0200
Subject: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11
In-Reply-To: <CAK9Gx1fx=w29r1BSCYwBsxqe6SMKTMpQPj30xb0-5F+0nsudMg@mail.gmail.com>
References: <CAK9Gx1fx=w29r1BSCYwBsxqe6SMKTMpQPj30xb0-5F+0nsudMg@mail.gmail.com>
Message-ID: <CAKjRUT6UqCp0aLefOy_fD86nJP40qNNJ7RqoRvZ-khsPpvvKZg@mail.gmail.com>

Hi Peter,

I tried on my linux laptop (i7 + nvidia binary driver) and my results are
the same on OpenJDK 8 / 11:





*- Java: 1.8.0_181 25.181-b13oct. 09, 2018 4:29:31 PM polylinetest.Canvas
paintComponentINFOS: Paint Time: 0,078soct. 09, 2018 4:29:31 PM
polylinetest.Canvas paintComponentINFOS: Paint Time: 0,032s*





*- Java: 11 11+28oct. 09, 2018 4:33:17 PM polylinetest.Canvas
paintComponentINFO: Paint Time: 0,058soct. 09, 2018 4:33:17 PM
polylinetest.Canvas paintComponentINFO: Paint Time: 0,03s*

Maybe it is related to your hardware, as such graphics calls should be
handled direclty by the accelerated pipelines ... XRender on linux.

Here are netbeans hotspots:
Name Self Time Self Time (CPU) Total Time Total Time (CPU) Hits
sun.java2d.xr.XRRenderer$XRDrawHandler.drawLine (int, int, int, int) 599 ms
(8,9 %) 599 ms (39 %) 702 ms (0,8 %) 702 ms (1,3 %) 393
sun.java2d.xr.XRBackendNative.XRenderRectanglesNative[native] (int, byte,
short, short, short, short, int[], int) 327 ms (4,9 %) 327 ms (21,3 %) 327
ms (0,4 %) 327 ms (0,6 %) 21
sun.java2d.loops.ProcessPath.doProcessPath
(sun.java2d.loops.ProcessPath.ProcessHandler, java.awt.geom.Path2D.Float,
float, float) 109 ms (1,6 %) 109 ms (7,1 %) 836 ms (0,9 %) 836 ms (1,5 %) 21
sun.java2d.xr.XRDrawLine.rasterizeLine (sun.java2d.xr.GrowableRectArray,
int, int, int, int, int, int, int, int, boolean, boolean) 85,1 ms (1,3 %) 85,1
ms (5,5 %) 103 ms (0,1 %) 103 ms (0,2 %) 458
sun.awt.X11.XInputMethod.createXICNative[native] (long) 46,9 ms (0,7 %) 46,9
ms (3,1 %) 46,9 ms (0,1 %) 46,9 ms (0,1 %) 1
java.awt.geom.Path2D$Float.needRoom (boolean, int) 45,2 ms (0,7 %) 45,2 ms
(2,9 %) 76,7 ms (0,1 %) 76,7 ms (0,1 %) 30
java.util.Arrays.copyOf (float[], int) 21,9 ms (0,3 %) 21,9 ms (1,4 %) 23,0
ms (0 %) 23,0 ms (0 %) 28
sun.java2d.xr.GrowableIntArray.growArray () 20,5 ms (0,3 %) 20,5 ms
(1,3 %) 21,0
ms (0 %) 21,0 ms (0 %) 4
sun.java2d.loops.ProcessPath$DrawProcessHandler.PROCESS_LINE (int, int,
int, int, boolean, int[]) 10,3 ms (0,2 %) 10,3 ms (0,7 %) 716 ms (0,8 %) 716
ms (1,3 %) 391

Peter, what is your hardware & OS info ?

Laurent

PS: I made few modifs in your code:
diff --git a/src/polylinetest/Canvas.java b/src/polylinetest/Canvas.java
index 8aad48c..a355e18 100644
--- a/src/polylinetest/Canvas.java
+++ b/src/polylinetest/Canvas.java
@@ -1,17 +1,26 @@
 package polylinetest;

+import java.awt.Color;
+import java.awt.Dimension;
 import java.awt.Graphics;
 import java.awt.Graphics2D;
+import java.awt.event.ActionEvent;
+import java.awt.event.ActionListener;
 import java.util.Random;
 import java.util.logging.Level;
 import java.util.logging.Logger;
-import javax.swing.JComponent;
+import javax.swing.JPanel;
+import javax.swing.Timer;

-public class Canvas extends JComponent {
+public class Canvas extends JPanel {

     public static int SIZEGRADE = 16;

     public Canvas() {
+        super();
+        setPreferredSize(new Dimension(300, 200));
+        setBackground(Color.WHITE);
+
         Random rnd = new Random();
         int len = 1 << SIZEGRADE;
         xs = new int[len];
@@ -20,6 +29,19 @@ public class Canvas extends JComponent {
             xs[i] = rnd.nextInt(640);
             ys[i] = rnd.nextInt(480);
         }
+        final Timer t = new Timer(100, new ActionListener() {
+            int count = 0;
+            @Override
+            public void actionPerformed(ActionEvent e) {
+                repaint();
+                count++;
+                if (count > 20) {
+                    System.exit(0);
+                }
+            }
+        });
+        t.setRepeats(true);
+        t.start();
     }

     @Override
diff --git a/src/polylinetest/PolylineTest.java
b/src/polylinetest/PolylineTest.java
index 61c9e10..636c3b7 100644
--- a/src/polylinetest/PolylineTest.java
+++ b/src/polylinetest/PolylineTest.java
@@ -1,14 +1,29 @@
 package polylinetest;

+import java.awt.BorderLayout;
 import javax.swing.JFrame;
+import javax.swing.JPanel;

 public class PolylineTest {
+
     public static void main(String[] args) {
-        JFrame frame = new JFrame("polyline test");
-        frame.setSize(640, 480);
-        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
-        frame.getContentPane().add(new Canvas());
-        javax.swing.SwingUtilities.invokeLater(() ->
frame.setVisible(true));
+        System.out.println("Java: "+System.getProperty("java.version") + "
" + System.getProperty("java.vm.version"));
+
+        javax.swing.SwingUtilities.invokeLater(new Runnable() {
+            @Override
+            public void run() {
+                JFrame frame = new JFrame("polyline test");
+                frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
+
+                JPanel panel = new JPanel(new BorderLayout());
+                panel.add(new Canvas(), BorderLayout.CENTER);
+
+                frame.getContentPane().add(panel);
+
+                frame.pack();
+                frame.setVisible(true);
+            }
+        });
     }
-
+
 }

Le mar. 9 oct. 2018 ? 15:29, Peter Hull <peterhull90 at gmail.com> a ?crit :

> I posted this message first on Java Discuss and was asked to file a Java
> bug. It was also suggested I post it here for discussion.
>
> I've recently started using Java 11 and noticed that drawPolyline is
> much slower on my PC than it was on Java 8.
> Example, simplified code:
>     @Override
>     protected void paintComponent(Graphics g) {
>         super.paintComponent(g);
>         Graphics2D graphics = (Graphics2D) g;
>         long starttime = System.nanoTime();
>         graphics.drawPolyline(xs, ys, xs.length);
>         long endtime = System.nanoTime();
>         Logger.getLogger(this.getClass().getName()).log(Level.INFO,
> "Paint Time: {0}s", (double)(endtime-starttime) / 1.0e9);
>     }
> where xs[] and ys[] are large (65536 points) integer arrays. On Java 8 I
> get a paint time of 0.025s and on Java 11 it is 25s, i.e. factor of 1000.
>
> This may be related to JEP263 (HiDPI)
>
> I've got a recent Core i7 processor with Intel graphics, running Windows
> 10.
>
> With VisualVM I can see that all the time goes in drawPolyline, I can't
> get any more detail than that.
>
> I have done some experimentation with RenderingHints but nothing makes the
> JDK11 go as fast as JDK8.
>
> Is there anything else I can try to either improve matters or to provide a
> clearer idea of why there is such a difference?
>
> I have a self-contained NetBeans project if anyone wants to try to see
> they can reproduce this.
> https://github.com/pedro-w/PolylineTest.git
>
> Thanks,
> Peter
>
>
> Versions:
> openjdk version "11" 2018-09-25
> OpenJDK Runtime Environment 18.9 (build 11+28)
> OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)
>
> openjdk version "1.8.0-adoptopenjdk"
> OpenJDK Runtime Environment (build
> 1.8.0-adoptopenjdk-_2018_05_19_00_59-b00)
> OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode)
>
>

-- 
-- 
Laurent Bourg?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181009/d5b6a398/attachment-0001.html>

From brian.burkhalter at oracle.com  Tue Oct  9 23:22:55 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 9 Oct 2018 16:22:55 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8211962: Implicit narrowing in MacOSX
	java.desktop jsound
In-Reply-To: <F7B8CF43-B28F-42E0-A533-5614AF95C1F7@oracle.com>
References: <F7B8CF43-B28F-42E0-A533-5614AF95C1F7@oracle.com>
Message-ID: <20B87A5C-A1E9-4B11-9C79-3EFC740421BB@oracle.com>

Looping in 2d-dev.

> On Oct 9, 2018, at 4:17 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
> 
> [I'm not sure whether core-libs is the right list for java.desktop changes.] 
> 
> Please review this trivial fix of a build failure on MacOSX when
> compiling with C++11/14 enabled. An int value is being used in an
> initializer where an unsigned int is needed, which is not permitted
> since C++11.  The solution taken is to cast the value in the
> initializer.  A "better" solution would be to change the type of the
> value, but that has substantial fannout because there are many places
> in our code where signed ints were used instead of the unsigned ints
> used by the underlying MacOSX framework.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8211962
> 
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8211962/open.00/
> 
> Testing:
> mach5 tier1 on MacOSX (really just verifying it builds).
> 
> 


From peterhull90 at gmail.com  Wed Oct 10 08:22:01 2018
From: peterhull90 at gmail.com (Peter Hull)
Date: Wed, 10 Oct 2018 09:22:01 +0100
Subject: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11
In-Reply-To: <CAKjRUT6UqCp0aLefOy_fD86nJP40qNNJ7RqoRvZ-khsPpvvKZg@mail.gmail.com>
References: <CAK9Gx1fx=w29r1BSCYwBsxqe6SMKTMpQPj30xb0-5F+0nsudMg@mail.gmail.com>
 <CAKjRUT6UqCp0aLefOy_fD86nJP40qNNJ7RqoRvZ-khsPpvvKZg@mail.gmail.com>
Message-ID: <CAK9Gx1dHXTm_ctFjh0F+Mh3bMbkJ2wXhABXS7GJhCghwe_06Zw@mail.gmail.com>

On Tue, Oct 9, 2018 at 3:52 PM Laurent Bourg?s
<bourges.laurent at gmail.com> wrote:
> Peter, what is your hardware & OS info ?
It's an Intel core i7-8750H, 8GB RAM, intel UHD 630 graphics
Windows 10 Pro 1803 build 17134.320

Note that Java 8 is still 'fast' so there must be some difference
between 8 & 11.

I saw that on Java 11, the window size was bigger. I assume this is
due to the HiDPI support added in Java 9 (my display scaling is set to
125%, which is the 'recommended' setting)

Are there any options I can pass to java.exe which would turn off
scaling - that might help to narrow down the problem.

By the way, I tried it on a Mac, it was also 'fast', so it just seems
to be Windows at the moment. I would appreciate it if someone else on
Windows could check it out.

Thanks,
Peter

From bourges.laurent at gmail.com  Wed Oct 10 10:55:03 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Wed, 10 Oct 2018 12:55:03 +0200
Subject: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11
In-Reply-To: <CAK9Gx1dHXTm_ctFjh0F+Mh3bMbkJ2wXhABXS7GJhCghwe_06Zw@mail.gmail.com>
References: <CAK9Gx1fx=w29r1BSCYwBsxqe6SMKTMpQPj30xb0-5F+0nsudMg@mail.gmail.com>
 <CAKjRUT6UqCp0aLefOy_fD86nJP40qNNJ7RqoRvZ-khsPpvvKZg@mail.gmail.com>
 <CAK9Gx1dHXTm_ctFjh0F+Mh3bMbkJ2wXhABXS7GJhCghwe_06Zw@mail.gmail.com>
Message-ID: <CAKjRUT6fe+SLCO0aHXQm76CrLZJfxfK6vG6d5ZXZaB4ocEm-GA@mail.gmail.com>

Peter,
What is the corresponding bug ?


> > Peter, what is your hardware & OS info ?
> It's an Intel core i7-8750H, 8GB RAM, intel UHD 630 graphics
> Windows 10 Pro 1803 build 17134.320
>
> Note that Java 8 is still 'fast' so there must be some difference
> between 8 & 11.
>
> I saw that on Java 11, the window size was bigger. I assume this is
> due to the HiDPI support added in Java 9 (my display scaling is set to
> 125%, which is the 'recommended' setting)
>
> Are there any options I can pass to java.exe which would turn off
> scaling - that might help to narrow down the problem.
>

I think it is -Djava2d.ui.scale=1.0 AFAIR.


> By the way, I tried it on a Mac, it was also 'fast', so it just seems
> to be Windows at the moment. I would appreciate it if someone else on
> Windows could check it out.
>

I can run tests in windows but i5+ discrete nvidia card.

You should run java2d in verbose mode to see if your intel gpu is not
supported by jdk11.
 It could then use software rendering as fallback and explain the slowdown.

Cheers,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181010/aec9256f/attachment.html>

From peterhull90 at gmail.com  Wed Oct 10 12:21:54 2018
From: peterhull90 at gmail.com (Peter Hull)
Date: Wed, 10 Oct 2018 13:21:54 +0100
Subject: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11
In-Reply-To: <CAKjRUT6fe+SLCO0aHXQm76CrLZJfxfK6vG6d5ZXZaB4ocEm-GA@mail.gmail.com>
References: <CAK9Gx1fx=w29r1BSCYwBsxqe6SMKTMpQPj30xb0-5F+0nsudMg@mail.gmail.com>
 <CAKjRUT6UqCp0aLefOy_fD86nJP40qNNJ7RqoRvZ-khsPpvvKZg@mail.gmail.com>
 <CAK9Gx1dHXTm_ctFjh0F+Mh3bMbkJ2wXhABXS7GJhCghwe_06Zw@mail.gmail.com>
 <CAKjRUT6fe+SLCO0aHXQm76CrLZJfxfK6vG6d5ZXZaB4ocEm-GA@mail.gmail.com>
Message-ID: <CAK9Gx1fUrrsPTug5n0fNGEkJ=_J8L2JAqubZtNNuNL9ZaS3KxQ@mail.gmail.com>

On Wed, 10 Oct 2018 at 11:55 Laurent Bourg?s <bourges.laurent at gmail.com> wrote:
>
> Peter,
> What is the corresponding bug ?
>
 I don't know; I filled in the details and it said they would let me
know the bug number if & when it was accepted.
>
>
> I think it is -Djava2d.ui.scale=1.0 AFAIR.

It's
-Dsun.java2d.uiScale=1.0
And this does make it fast again for me (paint time < 0.1sec)!

How do I make it run verbosely, I tried
-Dsun.java2d.trace=log,out:log.txt,verbose
But didn't see anything helpful.

Thanks,
Peter

From peterhull90 at gmail.com  Wed Oct 10 13:07:26 2018
From: peterhull90 at gmail.com (Peter Hull)
Date: Wed, 10 Oct 2018 14:07:26 +0100
Subject: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11
In-Reply-To: <CAK9Gx1fUrrsPTug5n0fNGEkJ=_J8L2JAqubZtNNuNL9ZaS3KxQ@mail.gmail.com>
References: <CAK9Gx1fx=w29r1BSCYwBsxqe6SMKTMpQPj30xb0-5F+0nsudMg@mail.gmail.com>
 <CAKjRUT6UqCp0aLefOy_fD86nJP40qNNJ7RqoRvZ-khsPpvvKZg@mail.gmail.com>
 <CAK9Gx1dHXTm_ctFjh0F+Mh3bMbkJ2wXhABXS7GJhCghwe_06Zw@mail.gmail.com>
 <CAKjRUT6fe+SLCO0aHXQm76CrLZJfxfK6vG6d5ZXZaB4ocEm-GA@mail.gmail.com>
 <CAK9Gx1fUrrsPTug5n0fNGEkJ=_J8L2JAqubZtNNuNL9ZaS3KxQ@mail.gmail.com>
Message-ID: <CAK9Gx1czsrxtuVUo_sCbY6LR3W2wTLbgOo6TOPWZY0vEyKhtUQ@mail.gmail.com>

On Wed, Oct 10, 2018 at 1:21 PM Peter Hull <peterhull90 at gmail.com> wrote:
> -Dsun.java2d.uiScale=1.0
> And this does make it fast again for me (paint time < 0.1sec)!

Also I tried on an older system with "Intel HD Graphics 4600" and it
did not have the slow down problem. So it seems to be quite specific
to my system.

From philip.race at oracle.com  Wed Oct 10 15:41:01 2018
From: philip.race at oracle.com (Philip Race)
Date: Wed, 10 Oct 2018 08:41:01 -0700
Subject: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11
In-Reply-To: <CAK9Gx1czsrxtuVUo_sCbY6LR3W2wTLbgOo6TOPWZY0vEyKhtUQ@mail.gmail.com>
References: <CAK9Gx1fx=w29r1BSCYwBsxqe6SMKTMpQPj30xb0-5F+0nsudMg@mail.gmail.com>
 <CAKjRUT6UqCp0aLefOy_fD86nJP40qNNJ7RqoRvZ-khsPpvvKZg@mail.gmail.com>
 <CAK9Gx1dHXTm_ctFjh0F+Mh3bMbkJ2wXhABXS7GJhCghwe_06Zw@mail.gmail.com>
 <CAKjRUT6fe+SLCO0aHXQm76CrLZJfxfK6vG6d5ZXZaB4ocEm-GA@mail.gmail.com>
 <CAK9Gx1fUrrsPTug5n0fNGEkJ=_J8L2JAqubZtNNuNL9ZaS3KxQ@mail.gmail.com>
 <CAK9Gx1czsrxtuVUo_sCbY6LR3W2wTLbgOo6TOPWZY0vEyKhtUQ@mail.gmail.com>
Message-ID: <5BBE1D8D.6040806@oracle.com>



  On 10/10/18, 6:07 AM, Peter Hull wrote:
> On Wed, Oct 10, 2018 at 1:21 PM Peter Hull<peterhull90 at gmail.com>  wrote:
>> -Dsun.java2d.uiScale=1.0
>> And this does make it fast again for me (paint time<  0.1sec)!

Which would sound like drawing wide lines on the software pipeline is 
slowing
it down which makes sense except the next statement potentially 
invalidates that :
> Also I tried on an older system with "Intel HD Graphics 4600" and it
> did not have the slow down problem. So it seems to be quite specific
> to my system.
Did that older system actually have UI scaling ?
What was the uiScale factor you saw on your "slow" system and what
is it on the no-slowdown system ?

In other words does

-Dsun.java2d.uiScale=1.0

even change the physical size of the window on JDK 9/10/11 ?


Measure the actual pixels by using a ruler on your screen and  of
course you'll need to know the screen resolution you have in use
to do the calculation :

Screen width in pixels  X window width in inches / screen width in inches

-phil

From Bill.York at mathworks.com  Wed Oct 10 15:45:09 2018
From: Bill.York at mathworks.com (Bill York)
Date: Wed, 10 Oct 2018 15:45:09 +0000
Subject: [OpenJDK 2D-Dev] Crash in CGraphicsDevice.m
Message-ID: <BE0719D1-DD45-4B25-8254-2EB83FED8149@mathworks.com>

2d-dev folks,

I work on a product called MATLAB and we have about 60 reports from customers on Mac related to a crash in CGraphicsDevice.m

Please let  me know if this is the right way to report a crash and discuss getting it resolved.

Here are the details:

CGraphicsDevice.m is a native file in support of Java drawing and gets called from Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode

While I can?t reproduce the problem, it looks like the display pointer is becoming invalid for a time when the user?s laptop opens or closes.

Looking at this source code:

http://cr.openjdk.java.net/~serb/8000629/webrev.08/src/macosx/native/sun/awt/CGraphicsDevice.m.html

I see a direct call to CFStringCompare without a check for a NULL CFStringRef.


  *   (CFStringCompare(mode, CFSTR(kIO30BitDirectPixels), kCFCompareCaseInsensitive) == kCFCompareEqualTo)

I believe if this code returned 0, the crash would not occur though there may be some other cleanup in the surrounding call frames.

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181010/c09e2c86/attachment-0001.html>

From philip.race at oracle.com  Wed Oct 10 16:03:15 2018
From: philip.race at oracle.com (Philip Race)
Date: Wed, 10 Oct 2018 09:03:15 -0700
Subject: [OpenJDK 2D-Dev] Crash in CGraphicsDevice.m
In-Reply-To: <BE0719D1-DD45-4B25-8254-2EB83FED8149@mathworks.com>
References: <BE0719D1-DD45-4B25-8254-2EB83FED8149@mathworks.com>
Message-ID: <5BBE22C3.2030109@oracle.com>

The code you suspect has nothing to do with the webrev you list.
It was introduced in fixing https://bugs.openjdk.java.net/browse/JDK-7124247
So has been there since JDK 8 GA. Not recent .. perhaps you can tell us
more about your users JDK versions and what is the earliest that 
reproduces this crash ?

-phil.

On 10/10/18, 8:45 AM, Bill York wrote:
>
> 2d-dev folks,
>
> I work on a product called MATLAB and we have about 60 reports from 
> customers on Mac related to a crash in CGraphicsDevice.m
>
> Please let  me know if this is the right way to report a crash and 
> discuss getting it resolved.
>
> Here are the details:
>
> CGraphicsDevice.m is a native file in support of Java drawing and gets 
> called from Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode
>
> While I can?t reproduce the problem, it looks like the display pointer 
> is becoming invalid for a time when the user?s laptop opens or closes.
>
> Looking at this source code:
>
> http://cr.openjdk.java.net/~serb/8000629/webrev.08/src/macosx/native/sun/awt/CGraphicsDevice.m.html 
> <http://cr.openjdk.java.net/%7Eserb/8000629/webrev.08/src/macosx/native/sun/awt/CGraphicsDevice.m.html>
>
> I see a direct call to CFStringCompare without a check for a NULL 
> CFStringRef.
>
>   * (CFStringCompare(mode, CFSTR(kIO30BitDirectPixels),
>     kCFCompareCaseInsensitive) == kCFCompareEqualTo)
>
> I believe if this code returned 0, the crash would not occur though 
> there may be some other cleanup in the surrounding call frames.
>
> Bill
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181010/8052a3eb/attachment.html>

From Bill.York at mathworks.com  Wed Oct 10 17:56:20 2018
From: Bill.York at mathworks.com (Bill York)
Date: Wed, 10 Oct 2018 17:56:20 +0000
Subject: [OpenJDK 2D-Dev] Crash in CGraphicsDevice.m
In-Reply-To: <5BBE22C3.2030109@oracle.com>
References: <BE0719D1-DD45-4B25-8254-2EB83FED8149@mathworks.com>
 <5BBE22C3.2030109@oracle.com>
Message-ID: <4B4E6360-2762-4ACC-8C89-117398227F7D@mathworks.com>

Thanks for the response Phil, here?s what I know.

Reports show:

  *   Mac OS ? many versions 10.10 through 17.7
  *   Java - 8 u144-b01 (48 reports), 8 u152-b16 (12 reports) 8 u152-release-1136-b5 ? JetBrains (1 report)

Comments say:

  *   Screen change event.  I am using the jetbrains JRE, as you can see in the stack trace.
  *   I am on a mac and product crashes very often when I put my computer to sleep.
  *   Woke up computer after connecting to two external monitors.

I?ve annotated the function names with links to code I found on the OpenJDK site and the Apple site.

As an experiment, I created a simple X-Code project to examine how CFSTringCompare behaves when passed NULL. It does throw an EXC_BAD_ACCESS as is shown in the below stack trace. My example code is at the end of this message.

Stack trace shows:

[  7] 0x00006000001c5848                                   <unknown-module>+00000000
[  8] 0x00007fff3cc4e678 /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation+00140920 CFStringCompare<https://developer.apple.com/documentation/corefoundation/1542911-cfstringcompare?language=objc>+00000024
[  9] 0x00000001351a80f7 java/jre/maci64/jre/lib/libawt_lwawt.dylib+00119031 getBPPFromModeString<http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/macosx/native/sun/awt/CGraphicsDevice.m>+00000032 (see line 32)
[ 10] 0x00000001351a819f java/jre/maci64/jre/lib/libawt_lwawt.dylib+00119199 createJavaDisplayMode<http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/macosx/native/sun/awt/CGraphicsDevice.m>+00000053 (see line 130)
[ 11] 0x00000001351a841e java/jre/maci64/jre/lib/libawt_lwawt.dylib+00119838 Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode<http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/macosx/native/sun/awt/CGraphicsDevice.m>+00000031 (see line 267)

Example code:


#import <Foundation/Foundation.h>



static int getBPPFromModeString(CFStringRef mode)

{

    if ((CFStringCompare(mode, CFSTR(kIO30BitDirectPixels), kCFCompareCaseInsensitive) == kCFCompareEqualTo)) {

        // This is a strange mode, where we using 10 bits per RGB component and pack it into 32 bits

        // Java is not ready to work with this mode but we have to specify it as supported

        return 30;

    }

    else if (CFStringCompare(mode, CFSTR(IO32BitDirectPixels), kCFCompareCaseInsensitive) == kCFCompareEqualTo) {

        return 32;

    }

    else if (CFStringCompare(mode, CFSTR(IO16BitDirectPixels), kCFCompareCaseInsensitive) == kCFCompareEqualTo) {

        return 16;

    }

    else if (CFStringCompare(mode, CFSTR(IO8BitIndexedPixels), kCFCompareCaseInsensitive) == kCFCompareEqualTo) {

        return 8;

    }



    return 0;

}



int main(int argc, const char * argv[]) {

    @autoreleasepool {

        // insert code here...

        CFStringRef mode;

        getBPPFromModeString(mode);

        NSLog(@"Hello, World!");

    }

    return 0;

}


From: Philip Race <philip.race at oracle.com>
Organization: Oracle Corporation
Date: Wednesday, October 10, 2018 at 12:03 PM
To: Bill York <Bill.York at mathworks.com>
Cc: "2d-dev at openjdk.java.net" <2d-dev at openjdk.java.net>
Subject: Re: [OpenJDK 2D-Dev] Crash in CGraphicsDevice.m

The code you suspect has nothing to do with the webrev you list.
It was introduced in fixing https://bugs.openjdk.java.net/browse/JDK-7124247<https://bugs.openjdk.java.net/browse/JDK-7124247>
So has been there since JDK 8 GA. Not recent .. perhaps you can tell us
more about your users JDK versions and what is the earliest that reproduces this crash ?

-phil.

On 10/10/18, 8:45 AM, Bill York wrote:
2d-dev folks,

I work on a product called MATLAB and we have about 60 reports from customers on Mac related to a crash in CGraphicsDevice.m

Please let  me know if this is the right way to report a crash and discuss getting it resolved.

Here are the details:

CGraphicsDevice.m is a native file in support of Java drawing and gets called from Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode

While I can?t reproduce the problem, it looks like the display pointer is becoming invalid for a time when the user?s laptop opens or closes.

Looking at this source code:

http://cr.openjdk.java.net/~serb/8000629/webrev.08/src/macosx/native/sun/awt/CGraphicsDevice.m.html<http://cr.openjdk.java.net/%7Eserb/8000629/webrev.08/src/macosx/native/sun/awt/CGraphicsDevice.m.html>

I see a direct call to CFStringCompare without a check for a NULL CFStringRef.


  *   (CFStringCompare(mode, CFSTR(kIO30BitDirectPixels), kCFCompareCaseInsensitive) == kCFCompareEqualTo)

I believe if this code returned 0, the crash would not occur though there may be some other cleanup in the surrounding call frames.

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181010/63a5ac85/attachment-0001.html>

From bourges.laurent at gmail.com  Wed Oct 10 18:15:34 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Wed, 10 Oct 2018 20:15:34 +0200
Subject: [OpenJDK 2D-Dev] Setting the FreeType LCD filter
In-Reply-To: <f5ef2fa9-52bf-9799-a41f-134bce17276b@status6.com>
References: <f5ef2fa9-52bf-9799-a41f-134bce17276b@status6.com>
Message-ID: <CAKjRUT4CtKjG=k3m08-6_58bjM_OaFR3-3xCj0c=k_yOmuGm_A@mail.gmail.com>

Hi john,

It looks awesome & promising.

Phil, what do you think ?

PS: It is better to send plain text (long) email than sending external
links (github).

Laurent

Le lun. 8 oct. 2018 ? 22:24, John Neffenger <john at status6.com> a ?crit :

> Now that we fixed a font problem in JavaFX [1], let's fix the same
> problem in Java. I would like your feedback on the Request for
> Enhancement described below:
>
> OpenJDK FreeType Font Fix
> https://github.com/jgneff/openjdk-freetype
>
> Thank you,
> John
>
> [1] https://github.com/javafxports/openjdk-jfx/issues/229
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181010/d5fc9cf0/attachment.html>

From philip.race at oracle.com  Wed Oct 10 18:36:43 2018
From: philip.race at oracle.com (Philip Race)
Date: Wed, 10 Oct 2018 11:36:43 -0700
Subject: [OpenJDK 2D-Dev] Setting the FreeType LCD filter
In-Reply-To: <CAKjRUT4CtKjG=k3m08-6_58bjM_OaFR3-3xCj0c=k_yOmuGm_A@mail.gmail.com>
References: <f5ef2fa9-52bf-9799-a41f-134bce17276b@status6.com>
 <CAKjRUT4CtKjG=k3m08-6_58bjM_OaFR3-3xCj0c=k_yOmuGm_A@mail.gmail.com>
Message-ID: <5BBE46BB.5030405@oracle.com>

SFAIK OpenJDK still requires that fixes be posted on cr.openjdk.java.net
I don't think we are allowed to pull fixes from github, or to review 
changes there.
So an in-line patch would be better.
That will likely change with skara but not yet ..

Also reviews should start out with a thread with a bug ID.

I also need to look at how this patch applies (as in the sense if 'is 
applicable to')
openjdk. I thought this should be going through some JDK filtering already.
It did in the old closed source case.

-phil.

On 10/10/18, 11:15 AM, Laurent Bourg?s wrote:
> Hi john,
>
> It looks awesome & promising.
>
> Phil, what do you think ?
>
> PS: It is better to send plain text (long) email than sending external 
> links (github).
>
> Laurent
>
> Le lun. 8 oct. 2018 ? 22:24, John Neffenger <john at status6.com 
> <mailto:john at status6.com>> a ?crit :
>
>     Now that we fixed a font problem in JavaFX [1], let's fix the same
>     problem in Java. I would like your feedback on the Request for
>     Enhancement described below:
>
>     OpenJDK FreeType Font Fix
>     https://github.com/jgneff/openjdk-freetype
>
>     Thank you,
>     John
>
>     [1] https://github.com/javafxports/openjdk-jfx/issues/229
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181010/39cbef3b/attachment.html>

From philip.race at oracle.com  Wed Oct 10 20:33:36 2018
From: philip.race at oracle.com (Phil Race)
Date: Wed, 10 Oct 2018 13:33:36 -0700
Subject: [OpenJDK 2D-Dev] Crash in CGraphicsDevice.m
In-Reply-To: <4B4E6360-2762-4ACC-8C89-117398227F7D@mathworks.com>
References: <BE0719D1-DD45-4B25-8254-2EB83FED8149@mathworks.com>
 <5BBE22C3.2030109@oracle.com>
 <4B4E6360-2762-4ACC-8C89-117398227F7D@mathworks.com>
Message-ID: <f91d87b3-10a2-6f1e-226c-99dc26f88e79@oracle.com>

Hi,

I expect it would be a good & safe thing to do, to check for NULL.
But I don't know if all of these reports you have are down to that.
Did you get stack traces for all of them ?
We also have open bugs like
https://bugs.openjdk.java.net/browse/JDK-8146329
https://bugs.openjdk.java.net/browse/JDK-8133783
which look different.

-phil.

On 10/10/2018 10:56 AM, Bill York wrote:
>
> Thanks for the response Phil, here?s what I know.
>
> Reports show:
>
>   * Mac OS ? many versions 10.10 through 17.7
>   * Java - 8 u144-b01 (48 reports), 8 u152-b16 (12 reports) 8
>     u152-release-1136-b5 ? JetBrains (1 report)
>
> Comments say:
>
>   * Screen change event.? I am using the jetbrains JRE, as you can see
>     in the stack trace.
>   * I am on a mac and product crashes very often when I put my
>     computer to sleep.
>   * Woke up computer after connecting to two external monitors.
>
> I?ve annotated the function names with links to code I found on the 
> OpenJDK site and the Apple site.
>
> As an experiment, I created a simple X-Code project to examine how 
> CFSTringCompare behaves when passed NULL. It does throw an 
> EXC_BAD_ACCESS as is shown in the below stack trace. My example code 
> is at the end of this message.
>
> Stack trace shows:
>
> [? 7] 0x00006000001c5848 <unknown-module>+00000000
>
> [? 8] 0x00007fff3cc4e678 
> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation+00140920CFStringCompare 
> <https://developer.apple.com/documentation/corefoundation/1542911-cfstringcompare?language=objc>+00000024
>
> [? 9] 0x00000001351a80f7 
> java/jre/maci64/jre/lib/libawt_lwawt.dylib+00119031 
> getBPPFromModeString 
> <http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/macosx/native/sun/awt/CGraphicsDevice.m>+00000032 
> (see line 32)
>
> [ 10] 0x00000001351a819f 
> java/jre/maci64/jre/lib/libawt_lwawt.dylib+00119199 
> createJavaDisplayMode 
> <http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/macosx/native/sun/awt/CGraphicsDevice.m>+00000053 
> (see line 130)
>
> [ 11] 0x00000001351a841e 
> java/jre/maci64/jre/lib/libawt_lwawt.dylib+00119838 
> Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode 
> <http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/macosx/native/sun/awt/CGraphicsDevice.m>+00000031 
> (see line 267)
>
> Example code:
>
> #import <Foundation/Foundation.h>
>
> static int getBPPFromModeString(CFStringRef mode)
>
> {
>
> if((CFStringCompare(mode, CFSTR(kIO30BitDirectPixels), 
> kCFCompareCaseInsensitive) == kCFCompareEqualTo)) {
>
> // This is a strange mode, where we using 10 bits per RGB component 
> and pack it into 32 bits
>
> // Java is not ready to work with this mode but we have to specify it 
> as supported
>
> return 30;
>
> }
>
> elseif(CFStringCompare(mode, CFSTR(IO32BitDirectPixels), 
> kCFCompareCaseInsensitive) == kCFCompareEqualTo) {
>
> return 32;
>
> }
>
> elseif(CFStringCompare(mode, CFSTR(IO16BitDirectPixels), 
> kCFCompareCaseInsensitive) == kCFCompareEqualTo) {
>
> return 16;
>
> }
>
> elseif(CFStringCompare(mode, CFSTR(IO8BitIndexedPixels), 
> kCFCompareCaseInsensitive) == kCFCompareEqualTo) {
>
> return 8;
>
> }
>
> return0;
>
> }
>
> int main(int argc, const char * argv[]) {
>
> @autoreleasepool{
>
> // insert code here...
>
> CFStringRef mode;
>
> getBPPFromModeString(mode);
>
> NSLog(@"Hello, World!");
>
> }
>
> return0;
>
> }
>
> *From: *Philip Race <philip.race at oracle.com>
> *Organization: *Oracle Corporation
> *Date: *Wednesday, October 10, 2018 at 12:03 PM
> *To: *Bill York <Bill.York at mathworks.com>
> *Cc: *"2d-dev at openjdk.java.net" <2d-dev at openjdk.java.net>
> *Subject: *Re: [OpenJDK 2D-Dev] Crash in CGraphicsDevice.m
>
> The code you suspect has nothing to do with the webrev you list.
> It was introduced in fixing 
> https://bugs.openjdk.java.net/browse/JDK-7124247 
> <https://bugs.openjdk.java.net/browse/JDK-7124247>
> So has been there since JDK 8 GA. Not recent .. perhaps you can tell us
> more about your users JDK versions and what is the earliest that 
> reproduces this crash ?
>
> -phil.
>
> On 10/10/18, 8:45 AM, Bill York wrote:
>
>     2d-dev folks,
>
>     I work on a product called MATLAB and we have about 60 reports
>     from customers on Mac related to a crash in CGraphicsDevice.m
>
>     Please let? me know if this is the right way to report a crash and
>     discuss getting it resolved.
>
>     Here are the details:
>
>     CGraphicsDevice.m is a native file in support of Java drawing and
>     gets called from Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode
>
>     While I can?t reproduce the problem, it looks like the display
>     pointer is becoming invalid for a time when the user?s laptop
>     opens or closes.
>
>     Looking at this source code:
>
>     http://cr.openjdk.java.net/~serb/8000629/webrev.08/src/macosx/native/sun/awt/CGraphicsDevice.m.html
>     <http://cr.openjdk.java.net/%7Eserb/8000629/webrev.08/src/macosx/native/sun/awt/CGraphicsDevice.m.html>
>
>     I see a direct call to CFStringCompare without a check for a NULL
>     CFStringRef.
>
>       * (CFStringCompare(mode, CFSTR(kIO30BitDirectPixels),
>         kCFCompareCaseInsensitive) == kCFCompareEqualTo)
>
>     I believe if this code returned 0, the crash would not occur
>     though there may be some other cleanup in the surrounding call frames.
>
>     Bill
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181010/6219aee2/attachment-0001.html>

From philip.race at oracle.com  Wed Oct 10 21:07:41 2018
From: philip.race at oracle.com (Phil Race)
Date: Wed, 10 Oct 2018 14:07:41 -0700
Subject: [OpenJDK 2D-Dev] Setting the FreeType LCD filter
In-Reply-To: <5BBE46BB.5030405@oracle.com>
References: <f5ef2fa9-52bf-9799-a41f-134bce17276b@status6.com>
 <CAKjRUT4CtKjG=k3m08-6_58bjM_OaFR3-3xCj0c=k_yOmuGm_A@mail.gmail.com>
 <5BBE46BB.5030405@oracle.com>
Message-ID: <78df9292-ae14-effc-8b70-58f5489cf055@oracle.com>

 > I thought this should be going through some JDK filtering already.
 > It did in the old closed source case.

So in the old closed source case, we had our own little bit of code for 
filtering
the resultant bitmap. There's no code like that in freetypeScaler, and
code in ft_smooth_render_generic which applies the filter set by
FT_Library_SetLcdFilter does pretty much the same thing - it is applied
as a final step.

So I think it makes sense to call it here. If we can get a patch posted
I can review & test it.

-phil.

On 10/10/2018 11:36 AM, Philip Race wrote:
> SFAIK OpenJDK still requires that fixes be posted on cr.openjdk.java.net
> I don't think we are allowed to pull fixes from github, or to review 
> changes there.
> So an in-line patch would be better.
> That will likely change with skara but not yet ..
>
> Also reviews should start out with a thread with a bug ID.
>
> I also need to look at how this patch applies (as in the sense if 'is 
> applicable to')
> openjdk. I thought this should be going through some JDK filtering 
> already.
> It did in the old closed source case.
>
> -phil.
>
> On 10/10/18, 11:15 AM, Laurent Bourg?s wrote:
>> Hi john,
>>
>> It looks awesome & promising.
>>
>> Phil, what do you think ?
>>
>> PS: It is better to send plain text (long) email than sending 
>> external links (github).
>>
>> Laurent
>>
>> Le lun. 8 oct. 2018 ? 22:24, John Neffenger <john at status6.com 
>> <mailto:john at status6.com>> a ?crit?:
>>
>>     Now that we fixed a font problem in JavaFX [1], let's fix the same
>>     problem in Java. I would like your feedback on the Request for
>>     Enhancement described below:
>>
>>     OpenJDK FreeType Font Fix
>>     https://github.com/jgneff/openjdk-freetype
>>
>>     Thank you,
>>     John
>>
>>     [1] https://github.com/javafxports/openjdk-jfx/issues/229
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181010/84d3602d/attachment.html>

From bourges.laurent at gmail.com  Thu Oct 11 06:02:12 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Thu, 11 Oct 2018 08:02:12 +0200
Subject: [OpenJDK 2D-Dev] Setting the FreeType LCD filter
In-Reply-To: <f5ef2fa9-52bf-9799-a41f-134bce17276b@status6.com>
References: <f5ef2fa9-52bf-9799-a41f-134bce17276b@status6.com>
Message-ID: <CAKjRUT7dZnhca122+fowXLOyqdv30PXsa7r9VsWdpbBAQGYuww@mail.gmail.com>

Hi john,

I can sponsor you, preparing an official webrev in openjdk 12, as phil
asked for.

Laurent

Le lun. 8 oct. 2018 ? 22:24, John Neffenger <john at status6.com> a ?crit :

> Now that we fixed a font problem in JavaFX [1], let's fix the same
> problem in Java. I would like your feedback on the Request for
> Enhancement described below:
>
> OpenJDK FreeType Font Fix
> https://github.com/jgneff/openjdk-freetype
>
> Thank you,
> John
>
> [1] https://github.com/javafxports/openjdk-jfx/issues/229
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181011/156e3ad8/attachment.html>

From prasanta.sadhukhan at oracle.com  Thu Oct 11 08:09:34 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 11 Oct 2018 13:39:34 +0530
Subject: [OpenJDK 2D-Dev] [12] RFR JDK-8212040: Compilation error due to
 wrong usage of NSPrintJobDispositionValue in mac10.12
Message-ID: <88ad790e-a1d0-c65c-d6d2-b7ca0c57a082@oracle.com>

Hi All,

Please review a build issue fix for usage of NSPrintJobDispositionValue 
in JDK-8211055 <https://bugs.openjdk.java.net/browse/JDK-8211055>: 
Provide print to a file (PDF) feature even when printer was not connected
It seems that NSPrintJobDispositionValue is added in 10.13 sdk 
[https://developer.apple.com/documentation/appkit/nsprintjobdispositionvalue?language=objc]
so using it in 10.12 or lower cause build issue.

Fix is to check for disposition value directly instead of storing in 
variable.
mach5 build is successful.

Bug:https://bugs.openjdk.java.net/browse/JDK-8212040
webrev: http://cr.openjdk.java.net/~psadhukhan/8212040/webrev/

Regards
Prasanta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181011/54d2a711/attachment.html>

From peterhull90 at gmail.com  Thu Oct 11 08:29:25 2018
From: peterhull90 at gmail.com (Peter Hull)
Date: Thu, 11 Oct 2018 09:29:25 +0100
Subject: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11
In-Reply-To: <5BBE1D8D.6040806@oracle.com>
References: <CAK9Gx1fx=w29r1BSCYwBsxqe6SMKTMpQPj30xb0-5F+0nsudMg@mail.gmail.com>
 <CAKjRUT6UqCp0aLefOy_fD86nJP40qNNJ7RqoRvZ-khsPpvvKZg@mail.gmail.com>
 <CAK9Gx1dHXTm_ctFjh0F+Mh3bMbkJ2wXhABXS7GJhCghwe_06Zw@mail.gmail.com>
 <CAKjRUT6fe+SLCO0aHXQm76CrLZJfxfK6vG6d5ZXZaB4ocEm-GA@mail.gmail.com>
 <CAK9Gx1fUrrsPTug5n0fNGEkJ=_J8L2JAqubZtNNuNL9ZaS3KxQ@mail.gmail.com>
 <CAK9Gx1czsrxtuVUo_sCbY6LR3W2wTLbgOo6TOPWZY0vEyKhtUQ@mail.gmail.com>
 <5BBE1D8D.6040806@oracle.com>
Message-ID: <CAK9Gx1c81CEgz4_EnsLeP0WXu82rfsWed-iYWqhtn12fJy+wrA@mail.gmail.com>

I can answer part of that, but I can't get access to the older system just now.

On Wed, Oct 10, 2018 at 4:41 PM Philip Race <philip.race at oracle.com> wrote:
> In other words does
>
> -Dsun.java2d.uiScale=1.0
>
> even change the physical size of the window on JDK 9/10/11 ?
>
Yes, because I can run the same jar under Java 8 and 11. Without the
scale option, the Java 11 window is bigger than the Java 8 one, by
about 1.25x (this corresponds to my system setting)
When I add the scale=1 option to both, they are both the same size
(and the same as JDK8 without any scaling)
I've attached 2 images so you can see what I mean, one is without any
scale option (and I labelled the approx size on this) and the other is
with -Dsun.java2d.uiScale=1.0.
The window title contains the system property "java.runtime.version"
so you can see which is which.

I do appreciate your help on this. It looks like it's coming down to
Intel's graphics driver, do you agree?

Pete
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sizes-scale1.png
Type: image/png
Size: 18563 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181011/c7bdca48/sizes-scale1-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sizes.png
Type: image/png
Size: 25752 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181011/c7bdca48/sizes-0001.png>

From Bill.York at mathworks.com  Thu Oct 11 11:00:13 2018
From: Bill.York at mathworks.com (Bill York)
Date: Thu, 11 Oct 2018 11:00:13 +0000
Subject: [OpenJDK 2D-Dev] Crash in CGraphicsDevice.m
In-Reply-To: <f91d87b3-10a2-6f1e-226c-99dc26f88e79@oracle.com>
References: <BE0719D1-DD45-4B25-8254-2EB83FED8149@mathworks.com>
 <5BBE22C3.2030109@oracle.com>
 <4B4E6360-2762-4ACC-8C89-117398227F7D@mathworks.com>
 <f91d87b3-10a2-6f1e-226c-99dc26f88e79@oracle.com>
Message-ID: <0EDC74AC-2FE3-4D0F-B02C-0DC0A827A5B2@mathworks.com>

Thanks Phil,

All the 61 reports I mentioned below have the same stack. In the same 30 days we also received:


  *   120 reports about https://bugs.openjdk.java.net/browse/JDK-8146329 or https://bugs.openjdk.java.net/browse/JDK-8133783
     *   I can?t tell the difference between those two bug reports
     *   Note this is fixed in the JetBrains OpenJDK here: https://bintray.com/jetbrains/intellij-jdk/download_file?file_path=jbsdk8u152b1136.5_osx_x64.tar.gz

Bill

From: Phil Race <philip.race at oracle.com>
Date: Wednesday, October 10, 2018 at 4:34 PM
To: Bill York <Bill.York at mathworks.com>
Cc: "2d-dev at openjdk.java.net" <2d-dev at openjdk.java.net>
Subject: Re: [OpenJDK 2D-Dev] Crash in CGraphicsDevice.m

Hi,

I expect it would be a good & safe thing to do, to check for NULL.
But I don't know if all of these reports you have are down to that.
Did you get stack traces for all of them ?
We also have open bugs like
https://bugs.openjdk.java.net/browse/JDK-8146329<https://bugs.openjdk.java.net/browse/JDK-8146329>
https://bugs.openjdk.java.net/browse/JDK-8133783<https://bugs.openjdk.java.net/browse/JDK-8133783>
which look different.

-phil.
On 10/10/2018 10:56 AM, Bill York wrote:
Thanks for the response Phil, here?s what I know.

Reports show:

  *   Mac OS ? many versions 10.10 through 17.7
  *   Java - 8 u144-b01 (48 reports), 8 u152-b16 (12 reports) 8 u152-release-1136-b5 ? JetBrains (1 report)

Comments say:

  *   Screen change event.  I am using the jetbrains JRE, as you can see in the stack trace.
  *   I am on a mac and product crashes very often when I put my computer to sleep.
  *   Woke up computer after connecting to two external monitors.

I?ve annotated the function names with links to code I found on the OpenJDK site and the Apple site.

As an experiment, I created a simple X-Code project to examine how CFSTringCompare behaves when passed NULL. It does throw an EXC_BAD_ACCESS as is shown in the below stack trace. My example code is at the end of this message.

Stack trace shows:

[  7] 0x00006000001c5848                                   <unknown-module>+00000000
[  8] 0x00007fff3cc4e678 /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation+00140920 CFStringCompare<https://developer.apple.com/documentation/corefoundation/1542911-cfstringcompare?language=objc>+00000024
[  9] 0x00000001351a80f7 java/jre/maci64/jre/lib/libawt_lwawt.dylib+00119031 getBPPFromModeString<http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/macosx/native/sun/awt/CGraphicsDevice.m>+00000032 (see line 32)
[ 10] 0x00000001351a819f java/jre/maci64/jre/lib/libawt_lwawt.dylib+00119199 createJavaDisplayMode<http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/macosx/native/sun/awt/CGraphicsDevice.m>+00000053 (see line 130)
[ 11] 0x00000001351a841e java/jre/maci64/jre/lib/libawt_lwawt.dylib+00119838 Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode<http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/macosx/native/sun/awt/CGraphicsDevice.m>+00000031 (see line 267)

Example code:


#import <Foundation/Foundation.h>



static int getBPPFromModeString(CFStringRef mode)

{

    if ((CFStringCompare(mode, CFSTR(kIO30BitDirectPixels), kCFCompareCaseInsensitive) == kCFCompareEqualTo)) {

        // This is a strange mode, where we using 10 bits per RGB component and pack it into 32 bits

        // Java is not ready to work with this mode but we have to specify it as supported

        return 30;

    }

    else if (CFStringCompare(mode, CFSTR(IO32BitDirectPixels), kCFCompareCaseInsensitive) == kCFCompareEqualTo) {

        return 32;

    }

    else if (CFStringCompare(mode, CFSTR(IO16BitDirectPixels), kCFCompareCaseInsensitive) == kCFCompareEqualTo) {

        return 16;

    }

    else if (CFStringCompare(mode, CFSTR(IO8BitIndexedPixels), kCFCompareCaseInsensitive) == kCFCompareEqualTo) {

        return 8;

    }



    return 0;

}



int main(int argc, const char * argv[]) {

    @autoreleasepool {

        // insert code here...

        CFStringRef mode;

        getBPPFromModeString(mode);

        NSLog(@"Hello, World!");

    }

    return 0;

}


From: Philip Race <philip.race at oracle.com><mailto:philip.race at oracle.com>
Organization: Oracle Corporation
Date: Wednesday, October 10, 2018 at 12:03 PM
To: Bill York <Bill.York at mathworks.com><mailto:Bill.York at mathworks.com>
Cc: "2d-dev at openjdk.java.net"<mailto:2d-dev at openjdk.java.net> <2d-dev at openjdk.java.net><mailto:2d-dev at openjdk.java.net>
Subject: Re: [OpenJDK 2D-Dev] Crash in CGraphicsDevice.m

The code you suspect has nothing to do with the webrev you list.
It was introduced in fixing https://bugs.openjdk.java.net/browse/JDK-7124247<https://bugs.openjdk.java.net/browse/JDK-7124247>
So has been there since JDK 8 GA. Not recent .. perhaps you can tell us
more about your users JDK versions and what is the earliest that reproduces this crash ?

-phil.

On 10/10/18, 8:45 AM, Bill York wrote:
2d-dev folks,

I work on a product called MATLAB and we have about 60 reports from customers on Mac related to a crash in CGraphicsDevice.m

Please let  me know if this is the right way to report a crash and discuss getting it resolved.

Here are the details:

CGraphicsDevice.m is a native file in support of Java drawing and gets called from Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode

While I can?t reproduce the problem, it looks like the display pointer is becoming invalid for a time when the user?s laptop opens or closes.

Looking at this source code:

http://cr.openjdk.java.net/~serb/8000629/webrev.08/src/macosx/native/sun/awt/CGraphicsDevice.m.html<http://cr.openjdk.java.net/%7Eserb/8000629/webrev.08/src/macosx/native/sun/awt/CGraphicsDevice.m.html>

I see a direct call to CFStringCompare without a check for a NULL CFStringRef.


  *   (CFStringCompare(mode, CFSTR(kIO30BitDirectPixels), kCFCompareCaseInsensitive) == kCFCompareEqualTo)

I believe if this code returned 0, the crash would not occur though there may be some other cleanup in the surrounding call frames.

Bill


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181011/ca9d6c81/attachment-0001.html>

From bourges.laurent at gmail.com  Thu Oct 11 11:15:49 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Thu, 11 Oct 2018 13:15:49 +0200
Subject: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11
In-Reply-To: <CAK9Gx1c81CEgz4_EnsLeP0WXu82rfsWed-iYWqhtn12fJy+wrA@mail.gmail.com>
References: <CAK9Gx1fx=w29r1BSCYwBsxqe6SMKTMpQPj30xb0-5F+0nsudMg@mail.gmail.com>
 <CAKjRUT6UqCp0aLefOy_fD86nJP40qNNJ7RqoRvZ-khsPpvvKZg@mail.gmail.com>
 <CAK9Gx1dHXTm_ctFjh0F+Mh3bMbkJ2wXhABXS7GJhCghwe_06Zw@mail.gmail.com>
 <CAKjRUT6fe+SLCO0aHXQm76CrLZJfxfK6vG6d5ZXZaB4ocEm-GA@mail.gmail.com>
 <CAK9Gx1fUrrsPTug5n0fNGEkJ=_J8L2JAqubZtNNuNL9ZaS3KxQ@mail.gmail.com>
 <CAK9Gx1czsrxtuVUo_sCbY6LR3W2wTLbgOo6TOPWZY0vEyKhtUQ@mail.gmail.com>
 <5BBE1D8D.6040806@oracle.com>
 <CAK9Gx1c81CEgz4_EnsLeP0WXu82rfsWed-iYWqhtn12fJy+wrA@mail.gmail.com>
Message-ID: <CAKjRUT61HwGRuUnU6D8WA8C1nMQr9tBVuKyLtAgyHtNKJJU=hw@mail.gmail.com>

Hi Peter,

I confirm that HiDPI support is causing your problem.

On linux (xrender), I added -Dsun.java2d.uiScale=2.5 and the performance
becomes poor ~ 3.3s vs 0.03s !

java -Dsun.java2d.uiScale=2.5 -DuseAA=false -jar dist/PolylineTest.jar
Java: 11 11+28
oct. 11, 2018 1:02:00 PM polylinetest.Canvas paintComponent
INFO: Paint Time: 3,781s
oct. 11, 2018 1:02:03 PM polylinetest.Canvas paintComponent
INFO: Paint Time: 3,003s
oct. 11, 2018 1:02:06 PM polylinetest.Canvas paintComponent
*INFO: Paint Time: 3,318s*

java -jar dist/PolylineTest.jar
Java: 11 11+28
oct. 11, 2018 12:50:33 PM polylinetest.Canvas paintComponent
INFO: Paint Time: 0,073s
oct. 11, 2018 12:50:33 PM polylinetest.Canvas paintComponent
INFO: Paint Time: 0,037s
oct. 11, 2018 12:50:33 PM polylinetest.Canvas paintComponent
*INFO: Paint Time: 0,029s*


I enabled antialiasing hint to use Marlin renderer and performance is
slightly better ~1.9s vs 3.3s.
Java: 11 11+28
oct. 11, 2018 1:01:27 PM polylinetest.Canvas paintComponent
INFO: Paint Time: 2,304s
oct. 11, 2018 1:01:29 PM polylinetest.Canvas paintComponent
INFO: Paint Time: 1,911s
oct. 11, 2018 1:01:31 PM polylinetest.Canvas paintComponent
*INFO: Paint Time: 1,881s*

Moreover, your polyline is very complicated (65K segments) so AWT (c code)
may have troubles in contrary to the Marlin renderer (pure java - AA
optimized code), that is faster and performs AA computations (8 times more
sampling).

I performed quick profiling using linux perf:
perf record -g java -Dsun.java2d.uiScale=2.5 -jar dist/PolylineTest.jar

Samples: 58K of event 'cycles:ppp', Event count (approx.): 48668354960,
DSO: libawt.so
  Children      Self  Command
Symbol                                                                  ?


*+   74,35%     0,00%  AWT-EventQueue-  [.]
Java_sun_java2d_pipe_ShapeSpanIterator_nextSpan                     ?+
74,35%    74,10%  AWT-EventQueue-  [.]
ShapeSINextSpan                                                     ?+
10,00%     0,05%  AWT-EventQueue-  [.]
Java_sun_java2d_pipe_ShapeSpanIterator_lineTo                       ?*
     0,22%     0,22%  AWT-EventQueue-  [.]
sortSegmentsByLeadingY                                              ?
     0,14%     0,14%  AWT-EventQueue-  [.]
appendSegment                                                       ?
     0,08%     0,00%  java             [.]
Java_sun_java2d_loops_GraphicsPrimitiveMgr_initIDs                  ?
     0,04%     0,04%  AWT-EventQueue-  [.]
subdivideLine.isra.0                                                ?
     0,03%     0,00%  java             [.]
AWT_OnLoad                                                          ?
     0,03%     0,00%  java             [.]
AWTIsHeadless                                                       ?
     0,02%     0,02%  AWT-EventQueue-  [.]
GetSpanData                                                         ?
     0,02%     0,00%  java             [.]
Java_sun_java2d_SurfaceData_initIDs                                 ?
     0,01%     0,00%  AWT-EventQueue-  [.]
initSegmentTable                                                    ?
     0,01%     0,00%  java             [.]
Java_sun_java2d_loops_GraphicsPrimitiveMgr_registerNativeLoops      ?
     0,01%     0,01%  AWT-EventQueue-  [.] free at plt
?
     0,00%     0,00%  java             [.]
RegisterPrimitives                                                  ?
     0,00%     0,00%  Java2D Disposer  [.]
SurfaceData_DisposeOps                                              ?
     0,00%     0,00%  AWT-EventQueue-  [.] memcpy at plt
?
     0,00%     0,00%  AWT-EventQueue-  [.] calloc at plt
?
     0,00%     0,00%  java             [.]
InitSimpleTypes.constprop.0                                         ?
     0,00%     0,00%  java             [.]
MapAccelFunction                                                    ?
     0,00%     0,00%  java             [.]
Java_sun_java2d_pipe_SpanClipRenderer_initIDs                       ?

I suspect that HiDPI implies software rendering instead of accelerated
rendering (xrender drawline, AFAIR).

However, I am not sure such performance issue can be fixed any time soon.
Workaround: use -Dsun.java2d.uiScale=1.0

Regards,
Laurent

Le jeu. 11 oct. 2018 ? 10:30, Peter Hull <peterhull90 at gmail.com> a ?crit :

> I can answer part of that, but I can't get access to the older system just
> now.
>
> On Wed, Oct 10, 2018 at 4:41 PM Philip Race <philip.race at oracle.com>
> wrote:
> > In other words does
> >
> > -Dsun.java2d.uiScale=1.0
> >
> > even change the physical size of the window on JDK 9/10/11 ?
> >
> Yes, because I can run the same jar under Java 8 and 11. Without the
> scale option, the Java 11 window is bigger than the Java 8 one, by
> about 1.25x (this corresponds to my system setting)
> When I add the scale=1 option to both, they are both the same size
> (and the same as JDK8 without any scaling)
> I've attached 2 images so you can see what I mean, one is without any
> scale option (and I labelled the approx size on this) and the other is
> with -Dsun.java2d.uiScale=1.0.
> The window title contains the system property "java.runtime.version"
> so you can see which is which.
>
> I do appreciate your help on this. It looks like it's coming down to
> Intel's graphics driver, do you agree?
>
> Pete
>


-- 
-- 
Laurent Bourg?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181011/4798aea3/attachment.html>

From peterhull90 at gmail.com  Thu Oct 11 11:26:48 2018
From: peterhull90 at gmail.com (Peter Hull)
Date: Thu, 11 Oct 2018 12:26:48 +0100
Subject: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11
In-Reply-To: <CAKjRUT61HwGRuUnU6D8WA8C1nMQr9tBVuKyLtAgyHtNKJJU=hw@mail.gmail.com>
References: <CAK9Gx1fx=w29r1BSCYwBsxqe6SMKTMpQPj30xb0-5F+0nsudMg@mail.gmail.com>
 <CAKjRUT6UqCp0aLefOy_fD86nJP40qNNJ7RqoRvZ-khsPpvvKZg@mail.gmail.com>
 <CAK9Gx1dHXTm_ctFjh0F+Mh3bMbkJ2wXhABXS7GJhCghwe_06Zw@mail.gmail.com>
 <CAKjRUT6fe+SLCO0aHXQm76CrLZJfxfK6vG6d5ZXZaB4ocEm-GA@mail.gmail.com>
 <CAK9Gx1fUrrsPTug5n0fNGEkJ=_J8L2JAqubZtNNuNL9ZaS3KxQ@mail.gmail.com>
 <CAK9Gx1czsrxtuVUo_sCbY6LR3W2wTLbgOo6TOPWZY0vEyKhtUQ@mail.gmail.com>
 <5BBE1D8D.6040806@oracle.com>
 <CAK9Gx1c81CEgz4_EnsLeP0WXu82rfsWed-iYWqhtn12fJy+wrA@mail.gmail.com>
 <CAKjRUT61HwGRuUnU6D8WA8C1nMQr9tBVuKyLtAgyHtNKJJU=hw@mail.gmail.com>
Message-ID: <CAK9Gx1dvB=rBoN99zUewSBGNjpthoBQi+AyzmQbFnv-cE7wY2Q@mail.gmail.com>

Hi Laurent,
Thanks for the detailed explanation. I quickly checked on the older
Windows system and the Java 11 window was the same size as the Java 8
one, implying no scaling was going on (I guess just because it has a
lower resolution monitor) - so that confirms your hypothesis.

If I use -Dsun.java2d.uiScale=1.0 that's OK for my laptop, it doesn't
matter if the window is a bit small. However I believe some higher end
systems have much higher scaling factors (2x, 3x?). Is there a general
way to specify a 1px line regardless of scaling, because in my case I
don't mind too much if it's a 'hair-line'?

By the way, my actual application doesn't have 65000 lines but it
draws 3 graphs with about 3000 points, which makes it noticeably slow
when resizing the Window. I suppose I should look into cutting down
the number of points somehow...

Pete

From bourges.laurent at gmail.com  Thu Oct 11 12:31:45 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Thu, 11 Oct 2018 14:31:45 +0200
Subject: [OpenJDK 2D-Dev] Setting the FreeType LCD filter
In-Reply-To: <CAKjRUT7dZnhca122+fowXLOyqdv30PXsa7r9VsWdpbBAQGYuww@mail.gmail.com>
References: <f5ef2fa9-52bf-9799-a41f-134bce17276b@status6.com>
 <CAKjRUT7dZnhca122+fowXLOyqdv30PXsa7r9VsWdpbBAQGYuww@mail.gmail.com>
Message-ID: <CAKjRUT5wM+wS4bofsXE3zvtHS39u_4QWX8SAVFWrW+7qw7YZhA@mail.gmail.com>

Hi John & Phil,

I propose the following patch against jdk/client (openjdk12):
diff -r ac510fd737eb
src/java.desktop/share/native/libfontmanager/freetypeScaler.c
--- a/src/java.desktop/share/native/libfontmanager/freetypeScaler.c     Thu
Oct 11 14:19:36 2018 +0530
+++ b/src/java.desktop/share/native/libfontmanager/freetypeScaler.c     Thu
Oct 11 13:47:04 2018 +0200
@@ -38,6 +38,7 @@
 #include FT_SIZES_H
 #include FT_OUTLINE_H
 #include FT_SYNTHESIS_H
+#include FT_LCD_FILTER_H

 #include "fontscaler.h"

@@ -316,6 +317,8 @@
         free(scalerInfo);
         return 0;
     }
+    /* enable LCD filter */
+    FT_Library_SetLcdFilter(scalerInfo->library, FT_LCD_FILTER_DEFAULT);

     return ptr_to_jlong(scalerInfo);
 }

I tested it against OpenJDK11 and it fixed the problem of color fringes on
my ubuntu 18.4 (see screenshot):
http://cr.openjdk.java.net/~lbourges/png/freetype_lcd_filter_jdk11_vs_jdk12.png
<http://www.google.com/url?q=http%3A%2F%2Fcr.openjdk.java.net%2F~lbourges%2Fpng%2Ffreetype_lcd_filter_jdk11_vs_jdk12.png&sa=D&sntz=1&usg=AFQjCNE0CAjfIZwQddrqcTNkQcg0sg4bOw>

Hope it helps,
Laurent

Le jeu. 11 oct. 2018 ? 08:02, Laurent Bourg?s <bourges.laurent at gmail.com> a
?crit :

> Hi john,
>
> I can sponsor you, preparing an official webrev in openjdk 12, as phil
> asked for.
>
> Laurent
>
> Le lun. 8 oct. 2018 ? 22:24, John Neffenger <john at status6.com> a ?crit :
>
>> Now that we fixed a font problem in JavaFX [1], let's fix the same
>> problem in Java. I would like your feedback on the Request for
>> Enhancement described below:
>>
>> OpenJDK FreeType Font Fix
>> https://github.com/jgneff/openjdk-freetype
>>
>> Thank you,
>> John
>>
>> [1] https://github.com/javafxports/openjdk-jfx/issues/229
>>
>

-- 
-- 
Laurent Bourg?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181011/a4a31ce3/attachment.html>

From bourges.laurent at gmail.com  Thu Oct 11 12:53:26 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Thu, 11 Oct 2018 14:53:26 +0200
Subject: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11
In-Reply-To: <CAK9Gx1dvB=rBoN99zUewSBGNjpthoBQi+AyzmQbFnv-cE7wY2Q@mail.gmail.com>
References: <CAK9Gx1fx=w29r1BSCYwBsxqe6SMKTMpQPj30xb0-5F+0nsudMg@mail.gmail.com>
 <CAKjRUT6UqCp0aLefOy_fD86nJP40qNNJ7RqoRvZ-khsPpvvKZg@mail.gmail.com>
 <CAK9Gx1dHXTm_ctFjh0F+Mh3bMbkJ2wXhABXS7GJhCghwe_06Zw@mail.gmail.com>
 <CAKjRUT6fe+SLCO0aHXQm76CrLZJfxfK6vG6d5ZXZaB4ocEm-GA@mail.gmail.com>
 <CAK9Gx1fUrrsPTug5n0fNGEkJ=_J8L2JAqubZtNNuNL9ZaS3KxQ@mail.gmail.com>
 <CAK9Gx1czsrxtuVUo_sCbY6LR3W2wTLbgOo6TOPWZY0vEyKhtUQ@mail.gmail.com>
 <5BBE1D8D.6040806@oracle.com>
 <CAK9Gx1c81CEgz4_EnsLeP0WXu82rfsWed-iYWqhtn12fJy+wrA@mail.gmail.com>
 <CAKjRUT61HwGRuUnU6D8WA8C1nMQr9tBVuKyLtAgyHtNKJJU=hw@mail.gmail.com>
 <CAK9Gx1dvB=rBoN99zUewSBGNjpthoBQi+AyzmQbFnv-cE7wY2Q@mail.gmail.com>
Message-ID: <CAKjRUT6RSjoWyPB0sPkqXkaBeHmA7q1JoY_n193_QU7rwnY0zA@mail.gmail.com>

Hi,

One last thing about Marlin renderer:
it is available since OpenJDK9 and you can tune its subpixels to let say
1x1 ie 1 pixel: -Dsun.java2d.renderer.subPixel_log2_X=0
-Dsun.java2d.renderer.subPixel_log2_Y=0

I ran again the 'slow' test on linux ~ 0.5s:
- 4x faster than Marlin AA defaults
- 6.5x faster than AWT C code (HiDPI)
- still 16x slower than accelerated pipeline (xrender)

OpenJDK Runtime Environment 18.9 (build 11+28)
JAVA_OPTS: -DuseAA=true -Dsun.java2d.uiScale=2.5
-Dsun.java2d.renderer.subPixel_log2_X=0
-Dsun.java2d.renderer.subPixel_log2_Y=0
Java: 11 11+28
oct. 11, 2018 2:36:12 PM polylinetest.Canvas paintComponent
INFO: Paint Time: 0,747s
oct. 11, 2018 2:36:12 PM polylinetest.Canvas paintComponent
INFO: Paint Time: 0,553s
oct. 11, 2018 2:36:13 PM polylinetest.Canvas paintComponent
INFO: Paint Time: 0,559s
oct. 11, 2018 2:36:13 PM polylinetest.Canvas paintComponent
INFO: Paint Time: 0,55s

Of course, you should enable antialiasing:

     @Override
     protected void paintComponent(Graphics g) {
         super.paintComponent(g);
         Graphics2D graphics = (Graphics2D) g;
+               if (USE_AA) {
+
graphics.setRenderingHint(RenderingHints.KEY_ANTIALIASING,
RenderingHints.VALUE_ANTIALIAS_ON);
+               }

PS: In OpenJFX, noAA rendering is using a specific Marlin renderer instance
(1x1 sampling) so it could be applied to Java2D noAA too.

Cheers,
Laurent

Le jeu. 11 oct. 2018 ? 13:27, Peter Hull <peterhull90 at gmail.com> a ?crit :

> Hi Laurent,
> Thanks for the detailed explanation. I quickly checked on the older
> Windows system and the Java 11 window was the same size as the Java 8
> one, implying no scaling was going on (I guess just because it has a
> lower resolution monitor) - so that confirms your hypothesis.
>
> If I use -Dsun.java2d.uiScale=1.0 that's OK for my laptop, it doesn't
> matter if the window is a bit small. However I believe some higher end
> systems have much higher scaling factors (2x, 3x?). Is there a general
> way to specify a 1px line regardless of scaling, because in my case I
> don't mind too much if it's a 'hair-line'?
>
> By the way, my actual application doesn't have 65000 lines but it
> draws 3 graphs with about 3000 points, which makes it noticeably slow
> when resizing the Window. I suppose I should look into cutting down
> the number of points somehow...
>
> Pete
>


-- 
-- 
Laurent Bourg?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181011/b8f1dc4a/attachment.html>

From krishna.addepalli at oracle.com  Thu Oct 11 13:38:46 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Thu, 11 Oct 2018 13:38:46 +0000 (UTC)
Subject: [OpenJDK 2D-Dev] RFR: 8211962: Implicit narrowing in MacOSX
 java.desktop jsound
In-Reply-To: <20B87A5C-A1E9-4B11-9C79-3EFC740421BB@oracle.com>
References: <F7B8CF43-B28F-42E0-A533-5614AF95C1F7@oracle.com>
 <20B87A5C-A1E9-4B11-9C79-3EFC740421BB@oracle.com>
Message-ID: <585042e6-7292-4fde-9f9c-5bb05dbfe279@default>

Hi Kim,

An alternative way to fix it would be to declare the loop variable itself as unsigned, since the channels can never be negative, but that would require you to cast to int in two places.
Also, when casting, it is better to use static_cast<unsigned>, rather than C style casting.

Thanks,
Krishna

-----Original Message-----
From: Brian Burkhalter 
Sent: Wednesday, October 10, 2018 4:53 AM
To: Kim Barrett <kim.barrett at oracle.com>; 2d-dev <2d-dev at openjdk.java.net>
Cc: Java Core Libs <core-libs-dev at openjdk.java.net>
Subject: Re: [OpenJDK 2D-Dev] RFR: 8211962: Implicit narrowing in MacOSX java.desktop jsound

Looping in 2d-dev.

> On Oct 9, 2018, at 4:17 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
> 
> [I'm not sure whether core-libs is the right list for java.desktop 
> changes.]
> 
> Please review this trivial fix of a build failure on MacOSX when 
> compiling with C++11/14 enabled. An int value is being used in an 
> initializer where an unsigned int is needed, which is not permitted 
> since C++11.  The solution taken is to cast the value in the 
> initializer.  A "better" solution would be to change the type of the 
> value, but that has substantial fannout because there are many places 
> in our code where signed ints were used instead of the unsigned ints 
> used by the underlying MacOSX framework.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8211962
> 
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8211962/open.00/
> 
> Testing:
> mach5 tier1 on MacOSX (really just verifying it builds).
> 
> 


From bourges.laurent at gmail.com  Thu Oct 11 18:41:07 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Thu, 11 Oct 2018 20:41:07 +0200
Subject: [OpenJDK 2D-Dev] Setting the FreeType LCD filter
In-Reply-To: <6fd0a68f-f9bf-b3b2-1ade-21a0ff3ead94@status6.com>
References: <f5ef2fa9-52bf-9799-a41f-134bce17276b@status6.com>
 <CAKjRUT4CtKjG=k3m08-6_58bjM_OaFR3-3xCj0c=k_yOmuGm_A@mail.gmail.com>
 <6fd0a68f-f9bf-b3b2-1ade-21a0ff3ead94@status6.com>
Message-ID: <CAKjRUT7jVfn_kmTh8ywEMj7f-Xr1+tavZUsf5BFw7Z5eA0ZjuA@mail.gmail.com>

John,

Sorry but attachments are rejected if larger than 100 kb, then your email
is being moderated.

You should put resources online, preferably on openjdk.java.net.

Maybe just send text and your diff only and keep images as link on github.

Laurent

Le jeu. 11 oct. 2018 ? 19:56, John Neffenger <john at status6.com> a ?crit :

> On 10/10/2018 11:15 AM, Laurent Bourg?s wrote:
> > It looks awesome & promising.
>
> Thank you, Laurent, for looking into it so quickly!
>
> > PS: It is better to send plain text (long) email than sending external
> > links (github).
>
> Thanks for the tip. Right, Web pages and repositories can be deleted, so
> here it is, for the record ...
>
> The symptoms of the problem are the same as in the link below, but they
> appear in AWT and Swing applications instead of JavaFX applications.
>
>    JDK-8188810: Fonts are blurry on Ubuntu 16.04 and Debian 9
>    https://bugs.openjdk.java.net/browse/JDK-8188810
>
> The description of the problem on the Java side follows.
>
> Synopsis: Reduce color fringes in FreeType subpixel rendering
>
> The text in Java applications often has severe color fringes when using
> OpenJDK on Ubuntu and other Debian-based distributions because the JDK
> fails to set the LCD filter. Adding two lines of code to the file
> freetypeScaler.c fixed the problem in my tests, without any regression
> errors for other Linux distributions. The patch is attached to this
> message as the file freetypeScaler.diff.
>
> There are some alternatives to setting the filter:
>
>    ? Bundle the FreeType library by default and always use the new
> Harmony subpixel rendering technique. This option removes the
> uncertainty in the library at the expense of an additional 4.6 megabytes
> to the installed size ? an increase of less than one percent. OpenJDK 12
> even includes the latest FreeType 2.9.1, a newer version than the one
> found on most systems.
>
>    ? Wait another year and see what changes are made to FreeType, if
> any, when the ClearType patents expire. This option, though, doesn?t
> solve the problem that users of Ubuntu and other Debian-based
> distributions have now.
>
> The problem originates in decisions made by the developers of FreeType,
> Debian, Fedora, and OpenJDK concerning the Microsoft ClearType patents [1].
>
>    ? In 2007, FreeType 2.3.0 added a compiler configuration macro to the
> file ftoption.h named FT_CONFIG_OPTION_SUBPIXEL_RENDERING. If defined,
> the FreeType library includes patented ClearType techniques in its
> subpixel rendering.
>
>      But there?s a catch. When the ClearType methods are enabled, the
> subpixel rendering is not filtered, which results in severe color
> fringes. Clients of the FreeType library must make an explicit call to
> the function FT_Library_SetLcdFilter to apply color filtering. The
> filter was disabled by default, explained one of its authors, ?to avoid
> major surprises to existing clients, including libXft and Cairo which
> already perform some wacky color filtering on top of FreeType.?
>
>    ? In 2009, Debian created a patch to FreeType 2.3.9, named
> enable-subpixel-rendering.patch, that defines the macro and enables
> ClearType-style rendering. The change log states, ?This is considered no
> more or less evil than the bytecode interpreter which we also enable.?
> Ubuntu, based on Debian, applies the patch as well. Fedora created the
> same patch in 2007, named freetype-2.3.0-enable-spr.patch, but does not
> apply the patch by default.
>
>    ? In 2017, FreeType 2.8.1 included a new subpixel rendering
> technique, called Harmony, that is nearly identical in output to the
> ClearType technique but uses a different algorithm, avoiding the
> patents. FreeType now uses Harmony subpixel rendering when the ClearType
> methods are disabled, with no need for clients to set the LCD filter.
> (This would have been a good time for Debian to remove its subpixel
> rendering patch.) The latest Fedora Workstation 28 runs FreeType 2.8.0,
> which does not include Harmony.
>
>    ? In 2019, the Microsoft ClearType patents expire.
>
> So now we have two variants of the FreeType library: one that requires a
> function call to set the LCD filter in Ubuntu and other distributions
> based on Debian, and another that doesn?t require the function call in
> Red Hat Enterprise Linux, Oracle Linux, and other distributions based on
> Fedora.
>
> To demonstrate the problem, I built four versions of the JDK from the
> latest OpenJDK sources. I built a version that uses the system FreeType
> library and another that uses the bundled FreeType library. Then I
> changed the OpenJDK code to set the default LCD filter and built the two
> versions again. The four builds were named:
>
>    jdk-12-system-lcdnone
>    jdk-12-system-lcddefault
>    jdk-12-bundled-lcdnone
>    jdk-12-bundled-lcddefault
>
> The system library is FreeType 2.8.1 in Ubuntu 18.04.1 LTS, which has
> the Debian patch applied (ClearType methods enabled), while the bundled
> library is FreeType 2.9.1 in OpenJDK 12, which uses the library default
> (ClearType methods disabled). I wrote a simple Java Swing application
> called FontDemo [2] that displays two text areas with the Adobe Source
> Code Pro font [3] in TTF and OTF formats (the latest non-variable
> download).
>
> The results are shown in the two images attached to this message:
>
>    fontdemo.png
>      Three screenshots of the FontDemo program
>
>    fontdemo-detail.png
>      Details from the screenshots scaled by 800 percent
>
> When using the Ubuntu system FreeType library, setting the LCD filter is
> critical. The screenshots show the ClearType-style rendering without
> setting the LCD filter, and after adding the change to set the filter.
> The ClearType configuration macro is defined in the Ubuntu build of
> FreeType, so the function to set the filter returns success (0) when
> called and applies color filtering.
>
> When using the OpenJDK bundled FreeType library, setting the LCD filter
> does nothing. The screenshots show the FreeType Harmony rendering, which
> is the same whether or not the LCD filter is set. The ClearType
> configuration macro is not defined in the OpenJDK build of FreeType, so
> the function to set the filter returns FT_Err_Unimplemented_Feature (7)
> when called and does nothing.
>
> The test system I used is a QEMU/KVM guest virtual machine running
> Ubuntu 18.04.1 LTS (Bionic Beaver) with the details shown below. The
> display is a 27-inch Dell UltraSharp U2717D monitor with a resolution of
> 2560 ? 1440 pixels at 109 pixels per inch.
>
> ubuntu at bionic:~$ uname -a
> Linux bionic 4.15.0-36-generic #39-Ubuntu SMP
>    Mon Sep 24 16:19:09 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
>
> ubuntu at bionic:~$ ldd --version
> ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27
>
> ubuntu at bionic:~$ getconf GNU_LIBPTHREAD_VERSION
> NPTL 2.27
>
> ubuntu at bionic:~$ $HOME/opt/jdk-12-system-lcdnone/bin/java -version
> openjdk version "12-internal" 2019-03-19
> OpenJDK Runtime Environment (build 12-internal+0-adhoc.ubuntu.jdk)
> OpenJDK 64-Bit Server VM (build 12-internal+0-adhoc.ubuntu.jdk, mixed mode)
>
> Below are the full test results using five versions of FreeType built
> first with the ClearType methods disabled (the default) and then again
> with them enabled. I ran all 10 libraries under OpenJDK 12, first with
> no LCD filter and then again after adding the code to set the default
> LCD filter.
>
> No LCD Filter
>
> 2008 FreeType 2.3.5 (libfreetype.so.6.3.16) in Ubuntu 8.04 LTS
>      ClearType Off: Grayscale, ClearType On: Mild fringes
>
> 2014 FreeType 2.5.2 (libfreetype.so.6.11.1) in Ubuntu 14.04 LTS
>      ClearType Off: Grayscale, ClearType On: Severe fringes
>
> 2016 FreeType 2.6.1 (libfreetype.so.6.12.1) in Ubuntu 16.04 LTS
>      ClearType Off: Grayscale, ClearType On: Severe fringes
>
> 2018 FreeType 2.8.1 (libfreetype.so.6.15.0) in Ubuntu 18.04 LTS
>      ClearType Off: Harmony, ClearType On: Severe fringes
>
> 2019 FreeType 2.9.1 (libfreetype.so.6.16.1) in OpenJDK 12
>      ClearType Off: Harmony, ClearType On: Severe fringes
>
> The OpenJDK does not set the FreeType LCD filter, so there are severe
> color fringes when using a FreeType library built with the ClearType
> methods enabled. The only reason the older FreeType 2.3.5 shows mild
> color fringes is because it uses full hinting, so the glyphs are simply
> too skinny to see their colors.
>
> Default LCD Filter
>
> 2008 FreeType 2.3.5 (libfreetype.so.6.3.16) in Ubuntu 8.04 LTS
>      ClearType Off: Grayscale, ClearType On: ClearType filtered
>
> 2014 FreeType 2.5.2 (libfreetype.so.6.11.1) in Ubuntu 14.04 LTS
>      ClearType Off: Grayscale, ClearType On: ClearType filtered
>
> 2016 FreeType 2.6.1 (libfreetype.so.6.12.1) in Ubuntu 16.04 LTS
>      ClearType Off: Grayscale, ClearType On: ClearType filtered
>
> 2018 FreeType 2.8.1 (libfreetype.so.6.15.0) in Ubuntu 18.04 LTS
>      ClearType Off: Harmony, ClearType On: ClearType filtered
>
> 2019 FreeType 2.9.1 (libfreetype.so.6.16.1) in OpenJDK 12
>      ClearType Off: Harmony, ClearType On: ClearType filtered
>
> After changing the OpenJDK to set the default LCD filter, there is no
> version of the FreeType library that shows the severe color fringes.
> Note that Fedora Workstation 28 includes FreeType 2.8.0 with the
> ClearType methods disabled, so it displays grayscale anti-aliasing for
> the OpenJDK whether it sets the LCD filter or not. (FreeType 2.8.0 does
> not include Harmony.)
>
> For background information on LCD filters see Section 2.2.1 [4] of The
> Raster Tragedy at Low-Resolution, which has an interactive demonstration
> of the filters used in ClearType (Microsoft), CoolType (Adobe), FreeType
> (open source), and Quartz 2D (Apple). Hover your mouse over each of the
> samples in the illustration to remove the filter.
>
> Below is the relevant section of the file ftoption.h in FreeType 2.9.1
> bundled with OpenJDK 12, edited for formatting:
>
> java.desktop/share/native/libfreetype/include/freetype/config/ftoption.h
>
> /*
> Uncomment the line below if you want to activate LCD rendering
> technology similar to ClearType in this build of the library.  This
> technology triples the resolution in the direction color subpixels.
> To mitigate color fringes inherent to this technology, you also need
> to explicitly set up LCD filtering.
>
> Note that this feature is covered by several Microsoft patents
> and should not be activated in any default build of the library.
> When this macro is not defined, FreeType offers alternative LCD
> rendering technology that produces excellent output without LCD
> filtering.
> */
> /* #define FT_CONFIG_OPTION_SUBPIXEL_RENDERING */
>
> [1] http://david.freetype.org/cleartype-patents.html
> [2]
>
> https://github.com/jgneff/openjdk-freetype/blob/master/src/org/status6/FontDemo.java
> [3] https://github.com/adobe-fonts/source-code-pro
> [4] http://rastertragedy.com/RTRCh2.htm#Sec21
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181011/9596f801/attachment-0001.html>

From john at status6.com  Thu Oct 11 19:08:07 2018
From: john at status6.com (John Neffenger)
Date: Thu, 11 Oct 2018 12:08:07 -0700
Subject: [OpenJDK 2D-Dev] Setting the FreeType LCD filter
In-Reply-To: <CAKjRUT7jVfn_kmTh8ywEMj7f-Xr1+tavZUsf5BFw7Z5eA0ZjuA@mail.gmail.com>
References: <f5ef2fa9-52bf-9799-a41f-134bce17276b@status6.com>
 <CAKjRUT4CtKjG=k3m08-6_58bjM_OaFR3-3xCj0c=k_yOmuGm_A@mail.gmail.com>
 <6fd0a68f-f9bf-b3b2-1ade-21a0ff3ead94@status6.com>
 <CAKjRUT7jVfn_kmTh8ywEMj7f-Xr1+tavZUsf5BFw7Z5eA0ZjuA@mail.gmail.com>
Message-ID: <fee1ba80-ae31-6692-e594-3d19c5170ae1@status6.com>

On 10/11/2018 11:41 AM, Laurent Bourg?s wrote:
> Maybe just send text and your diff only and keep images as link on github.

Right again. Here's just the text, no attachments, formatted in plain 
text as best I can. Thank you again for your help, Laurent.

The symptoms of the problem are the same as in the link below, but they 
appear in AWT and Swing applications instead of JavaFX applications.

JDK-8188810: Fonts are blurry on Ubuntu 16.04 and Debian 9
https://bugs.openjdk.java.net/browse/JDK-8188810

The description of the problem on the Java side follows.

Synopsis: Reduce color fringes in FreeType subpixel rendering

The text in Java applications often has severe color fringes when using 
OpenJDK on Ubuntu and other Debian-based distributions because the JDK 
fails to set the LCD filter. Adding two lines of code to the file 
freetypeScaler.c fixed the problem in my tests, without any regression 
errors for other Linux distributions. The patch is included at the very 
end of this message.

There are some alternatives to setting the filter:

   ? Bundle the FreeType library by default and always use the new 
Harmony subpixel rendering technique. This option removes the 
uncertainty in the library at the expense of an additional 4.6 megabytes 
to the installed size ? an increase of less than one percent. OpenJDK 12 
even includes the latest FreeType 2.9.1, a newer version than the one 
found on most systems.

   ? Wait another year and see what changes are made to FreeType, if 
any, when the ClearType patents expire. This option, though, doesn?t 
solve the problem that users of Ubuntu and other Debian-based 
distributions have now.

The problem originates in decisions made by the developers of FreeType, 
Debian, Fedora, and OpenJDK concerning the Microsoft ClearType patents [1].

   ? In 2007, FreeType 2.3.0 added a compiler configuration macro to the 
file ftoption.h named FT_CONFIG_OPTION_SUBPIXEL_RENDERING. If defined, 
the FreeType library includes patented ClearType techniques in its 
subpixel rendering.

     But there?s a catch. When the ClearType methods are enabled, the 
subpixel rendering is not filtered, which results in severe color 
fringes. Clients of the FreeType library must make an explicit call to 
the function FT_Library_SetLcdFilter to apply color filtering. The 
filter was disabled by default, explained one of its authors, ?to avoid 
major surprises to existing clients, including libXft and Cairo which 
already perform some wacky color filtering on top of FreeType.?

   ? In 2009, Debian created a patch to FreeType 2.3.9, named 
enable-subpixel-rendering.patch, that defines the macro and enables 
ClearType-style rendering. The change log states, ?This is considered no 
more or less evil than the bytecode interpreter which we also enable.? 
Ubuntu, based on Debian, applies the patch as well. Fedora created the 
same patch in 2007, named freetype-2.3.0-enable-spr.patch, but does not 
apply the patch by default.

   ? In 2017, FreeType 2.8.1 included a new subpixel rendering 
technique, called Harmony, that is nearly identical in output to the 
ClearType technique but uses a different algorithm, avoiding the 
patents. FreeType now uses Harmony subpixel rendering when the ClearType 
methods are disabled, with no need for clients to set the LCD filter. 
(This would have been a good time for Debian to remove its subpixel 
rendering patch.) The latest Fedora Workstation 28 runs FreeType 2.8.0, 
which does not include Harmony.

   ? In 2019, the Microsoft ClearType patents expire.

So now we have two variants of the FreeType library: one that requires a 
function call to set the LCD filter in Ubuntu and other distributions 
based on Debian, and another that doesn?t require the function call in 
Red Hat Enterprise Linux, Oracle Linux, and other distributions based on 
Fedora.

To demonstrate the problem, I built four versions of the JDK from the 
latest OpenJDK sources. I built a version that uses the system FreeType 
library and another that uses the bundled FreeType library. Then I 
changed the OpenJDK code to set the default LCD filter and built the two 
versions again. The four builds were named:

   jdk-12-system-lcdnone
   jdk-12-system-lcddefault
   jdk-12-bundled-lcdnone
   jdk-12-bundled-lcddefault

The system library is FreeType 2.8.1 in Ubuntu 18.04.1 LTS, which has 
the Debian patch applied (ClearType methods enabled), while the bundled 
library is FreeType 2.9.1 in OpenJDK 12, which uses the library default 
(ClearType methods disabled). I wrote a simple Java Swing application 
called FontDemo [2] that displays two text areas with the Adobe Source 
Code Pro font [3] in TTF and OTF formats (the latest non-variable download).

The results are shown in the two images below:

fontdemo.png
https://raw.githubusercontent.com/jgneff/openjdk-freetype/master/files/fontdemo.png

fontdemo-detail.png
https://raw.githubusercontent.com/jgneff/openjdk-freetype/master/files/fontdemo-detail.png

When using the Ubuntu system FreeType library, setting the LCD filter is 
critical. The screenshots show the ClearType-style rendering without 
setting the LCD filter, and after adding the change to set the filter. 
The ClearType configuration macro is defined in the Ubuntu build of 
FreeType, so the function to set the filter returns success (0) when 
called and applies color filtering.

When using the OpenJDK bundled FreeType library, setting the LCD filter 
does nothing. The screenshot shows the FreeType Harmony subpixel 
rendering, which is the same whether or not the LCD filter is set. The 
ClearType configuration macro is not defined in the OpenJDK build of 
FreeType, so the function to set the filter returns 
FT_Err_Unimplemented_Feature (7) when called and does nothing.

The test system I used is a QEMU/KVM guest virtual machine running 
Ubuntu 18.04.1 LTS (Bionic Beaver) with the details shown below. The 
display is a 27-inch Dell UltraSharp U2717D monitor with a resolution of 
2560 ? 1440 pixels at 109 pixels per inch.

ubuntu at bionic:~$ uname -a
Linux bionic 4.15.0-36-generic #39-Ubuntu SMP
   Mon Sep 24 16:19:09 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

ubuntu at bionic:~$ ldd --version
ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27

ubuntu at bionic:~$ getconf GNU_LIBPTHREAD_VERSION
NPTL 2.27

ubuntu at bionic:~$ $HOME/opt/jdk-12-system-lcdnone/bin/java -version
openjdk version "12-internal" 2019-03-19
OpenJDK Runtime Environment (build 12-internal+0-adhoc.ubuntu.jdk)
OpenJDK 64-Bit Server VM (build 12-internal+0-adhoc.ubuntu.jdk, mixed mode)

Below are the full test results using five versions of FreeType built 
first with the ClearType methods disabled (the default) and then again 
with them enabled. I ran all 10 libraries under OpenJDK 12, first with 
no LCD filter and then again after adding the code to set the default 
LCD filter.

No LCD Filter

2008 FreeType 2.3.5 (libfreetype.so.6.3.16) in Ubuntu 8.04 LTS
     ClearType Off: Grayscale, ClearType On: Mild fringes

2014 FreeType 2.5.2 (libfreetype.so.6.11.1) in Ubuntu 14.04 LTS
     ClearType Off: Grayscale, ClearType On: Severe fringes

2016 FreeType 2.6.1 (libfreetype.so.6.12.1) in Ubuntu 16.04 LTS
     ClearType Off: Grayscale, ClearType On: Severe fringes

2018 FreeType 2.8.1 (libfreetype.so.6.15.0) in Ubuntu 18.04 LTS
     ClearType Off: Harmony, ClearType On: Severe fringes

2019 FreeType 2.9.1 (libfreetype.so.6.16.1) in OpenJDK 12
     ClearType Off: Harmony, ClearType On: Severe fringes

The OpenJDK does not set the FreeType LCD filter, so there are severe 
color fringes when using a FreeType library built with the ClearType 
methods enabled. The only reason the older FreeType 2.3.5 shows mild 
color fringes is because it uses full hinting, so the glyphs are simply 
too skinny to see their colors.

Default LCD Filter

2008 FreeType 2.3.5 (libfreetype.so.6.3.16) in Ubuntu 8.04 LTS
     ClearType Off: Grayscale, ClearType On: ClearType filtered

2014 FreeType 2.5.2 (libfreetype.so.6.11.1) in Ubuntu 14.04 LTS
     ClearType Off: Grayscale, ClearType On: ClearType filtered

2016 FreeType 2.6.1 (libfreetype.so.6.12.1) in Ubuntu 16.04 LTS
     ClearType Off: Grayscale, ClearType On: ClearType filtered

2018 FreeType 2.8.1 (libfreetype.so.6.15.0) in Ubuntu 18.04 LTS
     ClearType Off: Harmony, ClearType On: ClearType filtered

2019 FreeType 2.9.1 (libfreetype.so.6.16.1) in OpenJDK 12
     ClearType Off: Harmony, ClearType On: ClearType filtered

After changing the OpenJDK to set the default LCD filter, there is no 
version of the FreeType library that shows the severe color fringes. 
Note that Fedora Workstation 28 includes FreeType 2.8.0 with the 
ClearType methods disabled, so it displays grayscale anti-aliasing for 
the OpenJDK whether it sets the LCD filter or not. (FreeType 2.8.0 does 
not include Harmony.)

For background information on LCD filters see Section 2.2.1 [4] of The 
Raster Tragedy at Low-Resolution, which has an interactive demonstration 
of the filters used in ClearType (Microsoft), CoolType (Adobe), FreeType 
(open source), and Quartz 2D (Apple). Hover your mouse over each of the 
samples in the illustration to remove the filter.

Below is the relevant section of the file ftoption.h in FreeType 2.9.1 
bundled with OpenJDK 12, edited for formatting:

java.desktop/share/native/libfreetype/include/freetype/config/ftoption.h

/*
Uncomment the line below if you want to activate LCD rendering
technology similar to ClearType in this build of the library.  This
technology triples the resolution in the direction color subpixels.
To mitigate color fringes inherent to this technology, you also need
to explicitly set up LCD filtering.

Note that this feature is covered by several Microsoft patents
and should not be activated in any default build of the library.
When this macro is not defined, FreeType offers alternative LCD
rendering technology that produces excellent output without LCD
filtering.
*/
/* #define FT_CONFIG_OPTION_SUBPIXEL_RENDERING */

Links

[1] http://david.freetype.org/cleartype-patents.html
[2] 
https://github.com/jgneff/openjdk-freetype/blob/master/src/org/status6/FontDemo.java
[3] https://github.com/adobe-fonts/source-code-pro
[4] http://rastertragedy.com/RTRCh2.htm#Sec21

Patch

diff -r 1aa9beac610e 
src/java.desktop/share/native/libfontmanager/freetypeScaler.c
--- a/src/java.desktop/share/native/libfontmanager/freetypeScaler.c	Thu 
Oct 04 16:39:07 2018 +0200
+++ b/src/java.desktop/share/native/libfontmanager/freetypeScaler.c	Thu 
Oct 11 08:30:00 2018 -0700
@@ -38,6 +38,7 @@
  #include FT_SIZES_H
  #include FT_OUTLINE_H
  #include FT_SYNTHESIS_H
+#include FT_LCD_FILTER_H

  #include "fontscaler.h"

@@ -397,6 +398,8 @@
          if (errCode == 0) {
              errCode = FT_Activate_Size(scalerInfo->face->size);
          }
+
+        FT_Library_SetLcdFilter(scalerInfo->library, 
FT_LCD_FILTER_DEFAULT);
      }

      return errCode;

From Bill.York at mathworks.com  Thu Oct 11 19:15:42 2018
From: Bill.York at mathworks.com (Bill York)
Date: Thu, 11 Oct 2018 19:15:42 +0000
Subject: [OpenJDK 2D-Dev] Crash in CGraphicsDevice.m
In-Reply-To: <0EDC74AC-2FE3-4D0F-B02C-0DC0A827A5B2@mathworks.com>
References: <BE0719D1-DD45-4B25-8254-2EB83FED8149@mathworks.com>
 <5BBE22C3.2030109@oracle.com>
 <4B4E6360-2762-4ACC-8C89-117398227F7D@mathworks.com>
 <f91d87b3-10a2-6f1e-226c-99dc26f88e79@oracle.com>
 <0EDC74AC-2FE3-4D0F-B02C-0DC0A827A5B2@mathworks.com>
Message-ID: <642BAED4-D9E7-41B4-97BB-ADEBA9C7B30E@mathworks.com>

Hey Phil,

As an update on this discussion, I pulled the latest OpenJDK 8 and got it to build on an OSX 10.75 Mac we have here.

To verify that an early return of 0 from getBPPFromModeString works without crashing, I forced getBPPFromModeString to return 0 every 5th call and then, while our app is running, I changed the display configuraton.

Through use of PRINTF, I verified that getBPPFromModeString got called and did an early return.

At first glance, it appears that a check for NULL with an early return of 0 could prevent the crash we are seeing.

While I can?t force the conditions that demonstrate the customer reported bug, it appears that this fix will help.

Bill

From: Bill York <Bill.York at mathworks.com>
Date: Thursday, October 11, 2018 at 7:00 AM
To: Phil Race <philip.race at oracle.com>
Cc: "2d-dev at openjdk.java.net" <2d-dev at openjdk.java.net>, Bill York <Bill.York at mathworks.com>
Subject: Re: [OpenJDK 2D-Dev] Crash in CGraphicsDevice.m

Thanks Phil,

All the 61 reports I mentioned below have the same stack. In the same 30 days we also received:


  *   120 reports about https://bugs.openjdk.java.net/browse/JDK-8146329 or https://bugs.openjdk.java.net/browse/JDK-8133783
     *   I can?t tell the difference between those two bug reports
     *   Note this is fixed in the JetBrains OpenJDK here: https://bintray.com/jetbrains/intellij-jdk/download_file?file_path=jbsdk8u152b1136.5_osx_x64.tar.gz

Bill

From: Phil Race <philip.race at oracle.com>
Date: Wednesday, October 10, 2018 at 4:34 PM
To: Bill York <Bill.York at mathworks.com>
Cc: "2d-dev at openjdk.java.net" <2d-dev at openjdk.java.net>
Subject: Re: [OpenJDK 2D-Dev] Crash in CGraphicsDevice.m

Hi,

I expect it would be a good & safe thing to do, to check for NULL.
But I don't know if all of these reports you have are down to that.
Did you get stack traces for all of them ?
We also have open bugs like
https://bugs.openjdk.java.net/browse/JDK-8146329<https://bugs.openjdk.java.net/browse/JDK-8146329>
https://bugs.openjdk.java.net/browse/JDK-8133783<https://bugs.openjdk.java.net/browse/JDK-8133783>
which look different.

-phil.
On 10/10/2018 10:56 AM, Bill York wrote:
Thanks for the response Phil, here?s what I know.

Reports show:

  *   Mac OS ? many versions 10.10 through 17.7
  *   Java - 8 u144-b01 (48 reports), 8 u152-b16 (12 reports) 8 u152-release-1136-b5 ? JetBrains (1 report)

Comments say:

  *   Screen change event.  I am using the jetbrains JRE, as you can see in the stack trace.
  *   I am on a mac and product crashes very often when I put my computer to sleep.
  *   Woke up computer after connecting to two external monitors.

I?ve annotated the function names with links to code I found on the OpenJDK site and the Apple site.

As an experiment, I created a simple X-Code project to examine how CFSTringCompare behaves when passed NULL. It does throw an EXC_BAD_ACCESS as is shown in the below stack trace. My example code is at the end of this message.

Stack trace shows:

[  7] 0x00006000001c5848                                   <unknown-module>+00000000
[  8] 0x00007fff3cc4e678 /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation+00140920 CFStringCompare<https://developer.apple.com/documentation/corefoundation/1542911-cfstringcompare?language=objc>+00000024
[  9] 0x00000001351a80f7 java/jre/maci64/jre/lib/libawt_lwawt.dylib+00119031 getBPPFromModeString<http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/macosx/native/sun/awt/CGraphicsDevice.m>+00000032 (see line 32)
[ 10] 0x00000001351a819f java/jre/maci64/jre/lib/libawt_lwawt.dylib+00119199 createJavaDisplayMode<http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/macosx/native/sun/awt/CGraphicsDevice.m>+00000053 (see line 130)
[ 11] 0x00000001351a841e java/jre/maci64/jre/lib/libawt_lwawt.dylib+00119838 Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode<http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/macosx/native/sun/awt/CGraphicsDevice.m>+00000031 (see line 267)

Example code:


#import <Foundation/Foundation.h>



static int getBPPFromModeString(CFStringRef mode)

{

    if ((CFStringCompare(mode, CFSTR(kIO30BitDirectPixels), kCFCompareCaseInsensitive) == kCFCompareEqualTo)) {

        // This is a strange mode, where we using 10 bits per RGB component and pack it into 32 bits

        // Java is not ready to work with this mode but we have to specify it as supported

        return 30;

    }

    else if (CFStringCompare(mode, CFSTR(IO32BitDirectPixels), kCFCompareCaseInsensitive) == kCFCompareEqualTo) {

        return 32;

    }

    else if (CFStringCompare(mode, CFSTR(IO16BitDirectPixels), kCFCompareCaseInsensitive) == kCFCompareEqualTo) {

        return 16;

    }

    else if (CFStringCompare(mode, CFSTR(IO8BitIndexedPixels), kCFCompareCaseInsensitive) == kCFCompareEqualTo) {

        return 8;

    }



    return 0;

}



int main(int argc, const char * argv[]) {

    @autoreleasepool {

        // insert code here...

        CFStringRef mode;

        getBPPFromModeString(mode);

        NSLog(@"Hello, World!");

    }

    return 0;

}


From: Philip Race <philip.race at oracle.com><mailto:philip.race at oracle.com>
Organization: Oracle Corporation
Date: Wednesday, October 10, 2018 at 12:03 PM
To: Bill York <Bill.York at mathworks.com><mailto:Bill.York at mathworks.com>
Cc: "2d-dev at openjdk.java.net"<mailto:2d-dev at openjdk.java.net> <2d-dev at openjdk.java.net><mailto:2d-dev at openjdk.java.net>
Subject: Re: [OpenJDK 2D-Dev] Crash in CGraphicsDevice.m

The code you suspect has nothing to do with the webrev you list.
It was introduced in fixing https://bugs.openjdk.java.net/browse/JDK-7124247<https://bugs.openjdk.java.net/browse/JDK-7124247>
So has been there since JDK 8 GA. Not recent .. perhaps you can tell us
more about your users JDK versions and what is the earliest that reproduces this crash ?

-phil.

On 10/10/18, 8:45 AM, Bill York wrote:
2d-dev folks,

I work on a product called MATLAB and we have about 60 reports from customers on Mac related to a crash in CGraphicsDevice.m

Please let  me know if this is the right way to report a crash and discuss getting it resolved.

Here are the details:

CGraphicsDevice.m is a native file in support of Java drawing and gets called from Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode

While I can?t reproduce the problem, it looks like the display pointer is becoming invalid for a time when the user?s laptop opens or closes.

Looking at this source code:

http://cr.openjdk.java.net/~serb/8000629/webrev.08/src/macosx/native/sun/awt/CGraphicsDevice.m.html<http://cr.openjdk.java.net/%7Eserb/8000629/webrev.08/src/macosx/native/sun/awt/CGraphicsDevice.m.html>

I see a direct call to CFStringCompare without a check for a NULL CFStringRef.


  *   (CFStringCompare(mode, CFSTR(kIO30BitDirectPixels), kCFCompareCaseInsensitive) == kCFCompareEqualTo)

I believe if this code returned 0, the crash would not occur though there may be some other cleanup in the surrounding call frames.

Bill



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181011/bd4f5b7b/attachment-0001.html>

From philip.race at oracle.com  Thu Oct 11 19:22:03 2018
From: philip.race at oracle.com (Phil Race)
Date: Thu, 11 Oct 2018 12:22:03 -0700
Subject: [OpenJDK 2D-Dev] Setting the FreeType LCD filter
In-Reply-To: <6fd0a68f-f9bf-b3b2-1ade-21a0ff3ead94@status6.com>
References: <f5ef2fa9-52bf-9799-a41f-134bce17276b@status6.com>
 <CAKjRUT4CtKjG=k3m08-6_58bjM_OaFR3-3xCj0c=k_yOmuGm_A@mail.gmail.com>
 <6fd0a68f-f9bf-b3b2-1ade-21a0ff3ead94@status6.com>
Message-ID: <a0c25274-0a73-da5a-d3df-1d1fec7947e2@oracle.com>

Very well done analysis of the options and very thorough testing of the 
effects
on the different libraries/platforms.


 > There are some alternatives to setting the filter:
 > ? ? Bundle the FreeType library by default

Although the build makes this easy to set as an option, we decided we 
prefer to
use the platform library on Linux - and Solaris for that matter - in our 
releases.

So setting this option is going to be needed for some years to come, until
even a Linux current release like Ubuntu 18.04 is obsolete.

We can't re-use the OpenJavaFX bug ID, and surprisingly I can't find an open
bug on this for 2D. So I've submitted 
https://bugs.openjdk.java.net/browse/JDK-8212071

And I've attached John's images to the bug report and pasted his email 
in there.



-phil.


On 10/11/2018 10:56 AM, John Neffenger wrote:
> On 10/10/2018 11:15 AM, Laurent Bourg?s wrote:
>> It looks awesome & promising.
>
> Thank you, Laurent, for looking into it so quickly!
>
>> PS: It is better to send plain text (long) email than sending 
>> external links (github).
>
> Thanks for the tip. Right, Web pages and repositories can be deleted, 
> so here it is, for the record ...
>
> The symptoms of the problem are the same as in the link below, but 
> they appear in AWT and Swing applications instead of JavaFX applications.
>
> ? JDK-8188810: Fonts are blurry on Ubuntu 16.04 and Debian 9
> ? https://bugs.openjdk.java.net/browse/JDK-8188810
>
> The description of the problem on the Java side follows.
>
> Synopsis: Reduce color fringes in FreeType subpixel rendering
>
> The text in Java applications often has severe color fringes when 
> using OpenJDK on Ubuntu and other Debian-based distributions because 
> the JDK fails to set the LCD filter. Adding two lines of code to the 
> file freetypeScaler.c fixed the problem in my tests, without any 
> regression errors for other Linux distributions. The patch is attached 
> to this message as the file freetypeScaler.diff.
>
> There are some alternatives to setting the filter:
>
> ? ? Bundle the FreeType library by default and always use the new 
> Harmony subpixel rendering technique. This option removes the 
> uncertainty in the library at the expense of an additional 4.6 
> megabytes to the installed size ? an increase of less than one 
> percent. OpenJDK 12 even includes the latest FreeType 2.9.1, a newer 
> version than the one found on most systems.
>
> ? ? Wait another year and see what changes are made to FreeType, if 
> any, when the ClearType patents expire. This option, though, doesn?t 
> solve the problem that users of Ubuntu and other Debian-based 
> distributions have now.
>
> The problem originates in decisions made by the developers of 
> FreeType, Debian, Fedora, and OpenJDK concerning the Microsoft 
> ClearType patents [1].
>
> ? ? In 2007, FreeType 2.3.0 added a compiler configuration macro to 
> the file ftoption.h named FT_CONFIG_OPTION_SUBPIXEL_RENDERING. If 
> defined, the FreeType library includes patented ClearType techniques 
> in its subpixel rendering.
>
> ??? But there?s a catch. When the ClearType methods are enabled, the 
> subpixel rendering is not filtered, which results in severe color 
> fringes. Clients of the FreeType library must make an explicit call to 
> the function FT_Library_SetLcdFilter to apply color filtering. The 
> filter was disabled by default, explained one of its authors, ?to 
> avoid major surprises to existing clients, including libXft and Cairo 
> which already perform some wacky color filtering on top of FreeType.?
>
> ? ? In 2009, Debian created a patch to FreeType 2.3.9, named 
> enable-subpixel-rendering.patch, that defines the macro and enables 
> ClearType-style rendering. The change log states, ?This is considered 
> no more or less evil than the bytecode interpreter which we also 
> enable.? Ubuntu, based on Debian, applies the patch as well. Fedora 
> created the same patch in 2007, named freetype-2.3.0-enable-spr.patch, 
> but does not apply the patch by default.
>
> ? ? In 2017, FreeType 2.8.1 included a new subpixel rendering 
> technique, called Harmony, that is nearly identical in output to the 
> ClearType technique but uses a different algorithm, avoiding the 
> patents. FreeType now uses Harmony subpixel rendering when the 
> ClearType methods are disabled, with no need for clients to set the 
> LCD filter. (This would have been a good time for Debian to remove its 
> subpixel rendering patch.) The latest Fedora Workstation 28 runs 
> FreeType 2.8.0, which does not include Harmony.
>
> ? ? In 2019, the Microsoft ClearType patents expire.
>
> So now we have two variants of the FreeType library: one that requires 
> a function call to set the LCD filter in Ubuntu and other 
> distributions based on Debian, and another that doesn?t require the 
> function call in Red Hat Enterprise Linux, Oracle Linux, and other 
> distributions based on Fedora.
>
> To demonstrate the problem, I built four versions of the JDK from the 
> latest OpenJDK sources. I built a version that uses the system 
> FreeType library and another that uses the bundled FreeType library. 
> Then I changed the OpenJDK code to set the default LCD filter and 
> built the two versions again. The four builds were named:
>
> ? jdk-12-system-lcdnone
> ? jdk-12-system-lcddefault
> ? jdk-12-bundled-lcdnone
> ? jdk-12-bundled-lcddefault
>
> The system library is FreeType 2.8.1 in Ubuntu 18.04.1 LTS, which has 
> the Debian patch applied (ClearType methods enabled), while the 
> bundled library is FreeType 2.9.1 in OpenJDK 12, which uses the 
> library default (ClearType methods disabled). I wrote a simple Java 
> Swing application called FontDemo [2] that displays two text areas 
> with the Adobe Source Code Pro font [3] in TTF and OTF formats (the 
> latest non-variable download).
>
> The results are shown in the two images attached to this message:
>
> ? fontdemo.png
> ??? Three screenshots of the FontDemo program
>
> ? fontdemo-detail.png
> ??? Details from the screenshots scaled by 800 percent
>
> When using the Ubuntu system FreeType library, setting the LCD filter 
> is critical. The screenshots show the ClearType-style rendering 
> without setting the LCD filter, and after adding the change to set the 
> filter. The ClearType configuration macro is defined in the Ubuntu 
> build of FreeType, so the function to set the filter returns success 
> (0) when called and applies color filtering.
>
> When using the OpenJDK bundled FreeType library, setting the LCD 
> filter does nothing. The screenshots show the FreeType Harmony 
> rendering, which is the same whether or not the LCD filter is set. The 
> ClearType configuration macro is not defined in the OpenJDK build of 
> FreeType, so the function to set the filter returns 
> FT_Err_Unimplemented_Feature (7) when called and does nothing.
>
> The test system I used is a QEMU/KVM guest virtual machine running 
> Ubuntu 18.04.1 LTS (Bionic Beaver) with the details shown below. The 
> display is a 27-inch Dell UltraSharp U2717D monitor with a resolution 
> of 2560 ? 1440 pixels at 109 pixels per inch.
>
> ubuntu at bionic:~$ uname -a
> Linux bionic 4.15.0-36-generic #39-Ubuntu SMP
> ? Mon Sep 24 16:19:09 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
>
> ubuntu at bionic:~$ ldd --version
> ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27
>
> ubuntu at bionic:~$ getconf GNU_LIBPTHREAD_VERSION
> NPTL 2.27
>
> ubuntu at bionic:~$ $HOME/opt/jdk-12-system-lcdnone/bin/java -version
> openjdk version "12-internal" 2019-03-19
> OpenJDK Runtime Environment (build 12-internal+0-adhoc.ubuntu.jdk)
> OpenJDK 64-Bit Server VM (build 12-internal+0-adhoc.ubuntu.jdk, mixed 
> mode)
>
> Below are the full test results using five versions of FreeType built 
> first with the ClearType methods disabled (the default) and then again 
> with them enabled. I ran all 10 libraries under OpenJDK 12, first with 
> no LCD filter and then again after adding the code to set the default 
> LCD filter.
>
> No LCD Filter
>
> 2008 FreeType 2.3.5 (libfreetype.so.6.3.16) in Ubuntu 8.04 LTS
> ??? ClearType Off: Grayscale, ClearType On: Mild fringes
>
> 2014 FreeType 2.5.2 (libfreetype.so.6.11.1) in Ubuntu 14.04 LTS
> ??? ClearType Off: Grayscale, ClearType On: Severe fringes
>
> 2016 FreeType 2.6.1 (libfreetype.so.6.12.1) in Ubuntu 16.04 LTS
> ??? ClearType Off: Grayscale, ClearType On: Severe fringes
>
> 2018 FreeType 2.8.1 (libfreetype.so.6.15.0) in Ubuntu 18.04 LTS
> ??? ClearType Off: Harmony, ClearType On: Severe fringes
>
> 2019 FreeType 2.9.1 (libfreetype.so.6.16.1) in OpenJDK 12
> ??? ClearType Off: Harmony, ClearType On: Severe fringes
>
> The OpenJDK does not set the FreeType LCD filter, so there are severe 
> color fringes when using a FreeType library built with the ClearType 
> methods enabled. The only reason the older FreeType 2.3.5 shows mild 
> color fringes is because it uses full hinting, so the glyphs are 
> simply too skinny to see their colors.
>
> Default LCD Filter
>
> 2008 FreeType 2.3.5 (libfreetype.so.6.3.16) in Ubuntu 8.04 LTS
> ??? ClearType Off: Grayscale, ClearType On: ClearType filtered
>
> 2014 FreeType 2.5.2 (libfreetype.so.6.11.1) in Ubuntu 14.04 LTS
> ??? ClearType Off: Grayscale, ClearType On: ClearType filtered
>
> 2016 FreeType 2.6.1 (libfreetype.so.6.12.1) in Ubuntu 16.04 LTS
> ??? ClearType Off: Grayscale, ClearType On: ClearType filtered
>
> 2018 FreeType 2.8.1 (libfreetype.so.6.15.0) in Ubuntu 18.04 LTS
> ??? ClearType Off: Harmony, ClearType On: ClearType filtered
>
> 2019 FreeType 2.9.1 (libfreetype.so.6.16.1) in OpenJDK 12
> ??? ClearType Off: Harmony, ClearType On: ClearType filtered
>
> After changing the OpenJDK to set the default LCD filter, there is no 
> version of the FreeType library that shows the severe color fringes. 
> Note that Fedora Workstation 28 includes FreeType 2.8.0 with the 
> ClearType methods disabled, so it displays grayscale anti-aliasing for 
> the OpenJDK whether it sets the LCD filter or not. (FreeType 2.8.0 
> does not include Harmony.)
>
> For background information on LCD filters see Section 2.2.1 [4] of The 
> Raster Tragedy at Low-Resolution, which has an interactive 
> demonstration of the filters used in ClearType (Microsoft), CoolType 
> (Adobe), FreeType (open source), and Quartz 2D (Apple). Hover your 
> mouse over each of the samples in the illustration to remove the filter.
>
> Below is the relevant section of the file ftoption.h in FreeType 2.9.1 
> bundled with OpenJDK 12, edited for formatting:
>
> java.desktop/share/native/libfreetype/include/freetype/config/ftoption.h
>
> /*
> Uncomment the line below if you want to activate LCD rendering
> technology similar to ClearType in this build of the library. This
> technology triples the resolution in the direction color subpixels.
> To mitigate color fringes inherent to this technology, you also need
> to explicitly set up LCD filtering.
>
> Note that this feature is covered by several Microsoft patents
> and should not be activated in any default build of the library.
> When this macro is not defined, FreeType offers alternative LCD
> rendering technology that produces excellent output without LCD
> filtering.
> */
> /* #define FT_CONFIG_OPTION_SUBPIXEL_RENDERING */
>
> [1] http://david.freetype.org/cleartype-patents.html
> [2] 
> https://github.com/jgneff/openjdk-freetype/blob/master/src/org/status6/FontDemo.java
> [3] https://github.com/adobe-fonts/source-code-pro
> [4] http://rastertragedy.com/RTRCh2.htm#Sec21


From Sergey.Bylokhov at oracle.com  Thu Oct 11 21:43:31 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 11 Oct 2018 14:43:31 -0700
Subject: [OpenJDK 2D-Dev] Crash in CGraphicsDevice.m
In-Reply-To: <BE0719D1-DD45-4B25-8254-2EB83FED8149@mathworks.com>
References: <BE0719D1-DD45-4B25-8254-2EB83FED8149@mathworks.com>
Message-ID: <4c6e82c6-b5c8-a2ca-2fc4-6ecb32b96ecb@oracle.com>

Hi, Bill.

The similar bug was reported recently:
https://bugs.openjdk.java.net/browse/JDK-8211992

The root cause is how we use CoreGraphics display ID. This identifier can become non-valid at any time therefore methods, which is using this id should be ready to it.

And this bug found a few places which does not take care about the rule above.

I am working on the fix for jdk12.

On 10/10/2018 08:45, Bill York wrote:
> 2d-dev folks,
> 
> I work on a product called MATLAB and we have about 60 reports from customers on Mac related to a crash in CGraphicsDevice.m
> 
> Please let? me know if this is the right way to report a crash and discuss getting it resolved.
> 
> Here are the details:
> 
> CGraphicsDevice.m is a native file in support of Java drawing and gets called from Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode
> 
> While I can?t reproduce the problem, it looks like the display pointer is becoming invalid for a time when the user?s laptop opens or closes.
> 
> Looking at this source code:
> 
> http://cr.openjdk.java.net/~serb/8000629/webrev.08/src/macosx/native/sun/awt/CGraphicsDevice.m.html
> 
> I see a direct call to CFStringCompare without a check for a NULL CFStringRef.
> 
>   * (CFStringCompare(mode, CFSTR(kIO30BitDirectPixels), kCFCompareCaseInsensitive) == kCFCompareEqualTo)
> 
> I believe if this code returned 0, the crash would not occur though there may be some other cleanup in the surrounding call frames.
> 
> Bill
> 


-- 
Best regards, Sergey.

From philip.race at oracle.com  Thu Oct 11 23:15:01 2018
From: philip.race at oracle.com (Phil Race)
Date: Thu, 11 Oct 2018 16:15:01 -0700
Subject: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11
In-Reply-To: <CAK9Gx1dvB=rBoN99zUewSBGNjpthoBQi+AyzmQbFnv-cE7wY2Q@mail.gmail.com>
References: <CAK9Gx1fx=w29r1BSCYwBsxqe6SMKTMpQPj30xb0-5F+0nsudMg@mail.gmail.com>
 <CAKjRUT6UqCp0aLefOy_fD86nJP40qNNJ7RqoRvZ-khsPpvvKZg@mail.gmail.com>
 <CAK9Gx1dHXTm_ctFjh0F+Mh3bMbkJ2wXhABXS7GJhCghwe_06Zw@mail.gmail.com>
 <CAKjRUT6fe+SLCO0aHXQm76CrLZJfxfK6vG6d5ZXZaB4ocEm-GA@mail.gmail.com>
 <CAK9Gx1fUrrsPTug5n0fNGEkJ=_J8L2JAqubZtNNuNL9ZaS3KxQ@mail.gmail.com>
 <CAK9Gx1czsrxtuVUo_sCbY6LR3W2wTLbgOo6TOPWZY0vEyKhtUQ@mail.gmail.com>
 <5BBE1D8D.6040806@oracle.com>
 <CAK9Gx1c81CEgz4_EnsLeP0WXu82rfsWed-iYWqhtn12fJy+wrA@mail.gmail.com>
 <CAKjRUT61HwGRuUnU6D8WA8C1nMQr9tBVuKyLtAgyHtNKJJU=hw@mail.gmail.com>
 <CAK9Gx1dvB=rBoN99zUewSBGNjpthoBQi+AyzmQbFnv-cE7wY2Q@mail.gmail.com>
Message-ID: <a7abd67d-b72c-ceb1-7d7e-78df32600394@oracle.com>


In my previous email I was asking only about the "older" system,
precisely because as you confirm below, I wanted to know that
it was operating on an unscaled graphics.

It is being triggered by the scale. If you add :
graphics.scale(1.25, 1.25)
in your application and run on 8 you'll see the window size is
not changed but the contents are and the test now runs slowly
like the JDK 9+ case.

I think most primitives (text, images, fills, gradients, untransformed
rectangle drawing) will be only slightly slower. The same if
you were drawing anti-aliased lines - they are going to be slow already 
by comparison.

A few similar primitives (drawArc, drawOval, drawPolygon ..) may be 
similarly
affected but drawPolyLine even has dedicated loops for single pixel wide 
lines
so may be the most affected when these loops can't be used.

So this is a kind of worse case difference. Untransformed, aliased lines 
are super fast.
Once you do anything like add anti-aliasing or a transform, they get slower.

Note: hidpi does not mean that acceleration is "turned off", rather that
some operations can no longer be sent to the accelerated pipeline, either
it doesn't support that mode, or we haven't implemented the necessary code
to invoke it for that mode.

In Peter's case on Intel there will be no acceleration, since we do not 
enable D3D
on Intel graphics cards. But on my system the time is identical whether 
I use D3D or not.

But there is something else going on here too.
Peter's test use 2^16 line segments.

On my windows system at 1.25 scale, this takes 55 seconds to run.
But 2^15 line segments completes in 10 seconds.
So 2 x the no. of lines takes approx 5 times as long to run ..

I have a modified version of Peter's program which breaks the polyline array
into subarrays which get passed to multiple calls to drawPolyline.
It misses joining the last point in ARR[N] to the first point in 
ARR[N+1] but
I think that should not make much difference but if someone wants to use
that in a real app they'll need to handle it.

What I see is that using the smaller arrays makes a big difference.

So instead of 60 seconds to draw one 65,536 element polyline, to
draw 64 polylines of 1,024 elements takes just 1.1 seconds.
Still not 0.05 but better.
 From what I can see it is being turned into a huge GeneralPath and
rendered as a Shape. Multiple smaller shapes perform better.
Perhaps we can add a loop that is specific to polygons that will handle
this better, but that isn't likely to be jumped on .. and obviously
it will never be *as* fast as narrow lines.

-phil.



On 10/11/2018 04:26 AM, Peter Hull wrote:
> Hi Laurent,
> Thanks for the detailed explanation. I quickly checked on the older
> Windows system and the Java 11 window was the same size as the Java 8
> one, implying no scaling was going on (I guess just because it has a
> lower resolution monitor) - so that confirms your hypothesis.
>
> If I use -Dsun.java2d.uiScale=1.0 that's OK for my laptop, it doesn't
> matter if the window is a bit small. However I believe some higher end
> systems have much higher scaling factors (2x, 3x?). Is there a general
> way to specify a 1px line regardless of scaling, because in my case I
> don't mind too much if it's a 'hair-line'?
>
> By the way, my actual application doesn't have 65000 lines but it
> draws 3 graphs with about 3000 points, which makes it noticeably slow
> when resizing the Window. I suppose I should look into cutting down
> the number of points somehow...
>
> Pete


From philip.race at oracle.com  Fri Oct 12 01:48:29 2018
From: philip.race at oracle.com (Philip Race)
Date: Thu, 11 Oct 2018 18:48:29 -0700
Subject: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11
In-Reply-To: <a7abd67d-b72c-ceb1-7d7e-78df32600394@oracle.com>
References: <CAK9Gx1fx=w29r1BSCYwBsxqe6SMKTMpQPj30xb0-5F+0nsudMg@mail.gmail.com>
 <CAKjRUT6UqCp0aLefOy_fD86nJP40qNNJ7RqoRvZ-khsPpvvKZg@mail.gmail.com>
 <CAK9Gx1dHXTm_ctFjh0F+Mh3bMbkJ2wXhABXS7GJhCghwe_06Zw@mail.gmail.com>
 <CAKjRUT6fe+SLCO0aHXQm76CrLZJfxfK6vG6d5ZXZaB4ocEm-GA@mail.gmail.com>
 <CAK9Gx1fUrrsPTug5n0fNGEkJ=_J8L2JAqubZtNNuNL9ZaS3KxQ@mail.gmail.com>
 <CAK9Gx1czsrxtuVUo_sCbY6LR3W2wTLbgOo6TOPWZY0vEyKhtUQ@mail.gmail.com>
 <5BBE1D8D.6040806@oracle.com>
 <CAK9Gx1c81CEgz4_EnsLeP0WXu82rfsWed-iYWqhtn12fJy+wrA@mail.gmail.com>
 <CAKjRUT61HwGRuUnU6D8WA8C1nMQr9tBVuKyLtAgyHtNKJJU=hw@mail.gmail.com>
 <CAK9Gx1dvB=rBoN99zUewSBGNjpthoBQi+AyzmQbFnv-cE7wY2Q@mail.gmail.com>
 <a7abd67d-b72c-ceb1-7d7e-78df32600394@oracle.com>
Message-ID: <5BBFFD6D.1010808@oracle.com>

And something else to try .. which I haven't tried, since I now believe
the problem isn't the drawing performance of a wide line, is to see
what happens if you do go that path - ie try 3,000 individual drawline 
calls.
It depends how much overhead matters whether it is better than (say)
breaking it into 100 calls with 30 points to drawPolyline ..

-phil.

On 10/11/18, 4:15 PM, Phil Race wrote:
>
>
> By the way, my actual application doesn't have 65000 lines but it
> draws 3 graphs with about 3000 points, which makes it noticeably slow
> when resizing the Window. I suppose I should look into cutting down
> the number of points somehow...

From bourges.laurent at gmail.com  Fri Oct 12 05:04:52 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Fri, 12 Oct 2018 07:04:52 +0200
Subject: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11
In-Reply-To: <a7abd67d-b72c-ceb1-7d7e-78df32600394@oracle.com>
References: <CAK9Gx1fx=w29r1BSCYwBsxqe6SMKTMpQPj30xb0-5F+0nsudMg@mail.gmail.com>
 <CAKjRUT6UqCp0aLefOy_fD86nJP40qNNJ7RqoRvZ-khsPpvvKZg@mail.gmail.com>
 <CAK9Gx1dHXTm_ctFjh0F+Mh3bMbkJ2wXhABXS7GJhCghwe_06Zw@mail.gmail.com>
 <CAKjRUT6fe+SLCO0aHXQm76CrLZJfxfK6vG6d5ZXZaB4ocEm-GA@mail.gmail.com>
 <CAK9Gx1fUrrsPTug5n0fNGEkJ=_J8L2JAqubZtNNuNL9ZaS3KxQ@mail.gmail.com>
 <CAK9Gx1czsrxtuVUo_sCbY6LR3W2wTLbgOo6TOPWZY0vEyKhtUQ@mail.gmail.com>
 <5BBE1D8D.6040806@oracle.com>
 <CAK9Gx1c81CEgz4_EnsLeP0WXu82rfsWed-iYWqhtn12fJy+wrA@mail.gmail.com>
 <CAKjRUT61HwGRuUnU6D8WA8C1nMQr9tBVuKyLtAgyHtNKJJU=hw@mail.gmail.com>
 <CAK9Gx1dvB=rBoN99zUewSBGNjpthoBQi+AyzmQbFnv-cE7wY2Q@mail.gmail.com>
 <a7abd67d-b72c-ceb1-7d7e-78df32600394@oracle.com>
Message-ID: <CAKjRUT7Odx3xaYykCRPbWLTHqc6AEV59wHjeQGCp4_41FYNvSQ@mail.gmail.com>

Phil,

It reminds me I have rewritten in Marlin renderer the crossing sort at
every scanline.
Pisces was using a trivial insertion sort but it became very slow when the
crossing count is large.
I adopted a special merge sort as crossings are mostly ordered: big win.

What sort algo is in action in drawPolyLine ?

Cheers,
Laurent

Le ven. 12 oct. 2018 ? 01:15, Phil Race <philip.race at oracle.com> a ?crit :

>
> In my previous email I was asking only about the "older" system,
> precisely because as you confirm below, I wanted to know that
> it was operating on an unscaled graphics.
>
> It is being triggered by the scale. If you add :
> graphics.scale(1.25, 1.25)
> in your application and run on 8 you'll see the window size is
> not changed but the contents are and the test now runs slowly
> like the JDK 9+ case.
>
> I think most primitives (text, images, fills, gradients, untransformed
> rectangle drawing) will be only slightly slower. The same if
> you were drawing anti-aliased lines - they are going to be slow already
> by comparison.
>
> A few similar primitives (drawArc, drawOval, drawPolygon ..) may be
> similarly
> affected but drawPolyLine even has dedicated loops for single pixel wide
> lines
> so may be the most affected when these loops can't be used.
>
> So this is a kind of worse case difference. Untransformed, aliased lines
> are super fast.
> Once you do anything like add anti-aliasing or a transform, they get
> slower.
>
> Note: hidpi does not mean that acceleration is "turned off", rather that
> some operations can no longer be sent to the accelerated pipeline, either
> it doesn't support that mode, or we haven't implemented the necessary code
> to invoke it for that mode.
>
> In Peter's case on Intel there will be no acceleration, since we do not
> enable D3D
> on Intel graphics cards. But on my system the time is identical whether
> I use D3D or not.
>
> But there is something else going on here too.
> Peter's test use 2^16 line segments.
>
> On my windows system at 1.25 scale, this takes 55 seconds to run.
> But 2^15 line segments completes in 10 seconds.
> So 2 x the no. of lines takes approx 5 times as long to run ..
>
> I have a modified version of Peter's program which breaks the polyline
> array
> into subarrays which get passed to multiple calls to drawPolyline.
> It misses joining the last point in ARR[N] to the first point in
> ARR[N+1] but
> I think that should not make much difference but if someone wants to use
> that in a real app they'll need to handle it.
>
> What I see is that using the smaller arrays makes a big difference.
>
> So instead of 60 seconds to draw one 65,536 element polyline, to
> draw 64 polylines of 1,024 elements takes just 1.1 seconds.
> Still not 0.05 but better.
>  From what I can see it is being turned into a huge GeneralPath and
> rendered as a Shape. Multiple smaller shapes perform better.
> Perhaps we can add a loop that is specific to polygons that will handle
> this better, but that isn't likely to be jumped on .. and obviously
> it will never be *as* fast as narrow lines.
>
> -phil.
>
>
>
> On 10/11/2018 04:26 AM, Peter Hull wrote:
> > Hi Laurent,
> > Thanks for the detailed explanation. I quickly checked on the older
> > Windows system and the Java 11 window was the same size as the Java 8
> > one, implying no scaling was going on (I guess just because it has a
> > lower resolution monitor) - so that confirms your hypothesis.
> >
> > If I use -Dsun.java2d.uiScale=1.0 that's OK for my laptop, it doesn't
> > matter if the window is a bit small. However I believe some higher end
> > systems have much higher scaling factors (2x, 3x?). Is there a general
> > way to specify a 1px line regardless of scaling, because in my case I
> > don't mind too much if it's a 'hair-line'?
> >
> > By the way, my actual application doesn't have 65000 lines but it
> > draws 3 graphs with about 3000 points, which makes it noticeably slow
> > when resizing the Window. I suppose I should look into cutting down
> > the number of points somehow...
> >
> > Pete
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181012/31fb034d/attachment.html>

From bourges.laurent at gmail.com  Fri Oct 12 09:18:02 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Fri, 12 Oct 2018 11:18:02 +0200
Subject: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11
In-Reply-To: <CAKjRUT7Odx3xaYykCRPbWLTHqc6AEV59wHjeQGCp4_41FYNvSQ@mail.gmail.com>
References: <CAK9Gx1fx=w29r1BSCYwBsxqe6SMKTMpQPj30xb0-5F+0nsudMg@mail.gmail.com>
 <CAKjRUT6UqCp0aLefOy_fD86nJP40qNNJ7RqoRvZ-khsPpvvKZg@mail.gmail.com>
 <CAK9Gx1dHXTm_ctFjh0F+Mh3bMbkJ2wXhABXS7GJhCghwe_06Zw@mail.gmail.com>
 <CAKjRUT6fe+SLCO0aHXQm76CrLZJfxfK6vG6d5ZXZaB4ocEm-GA@mail.gmail.com>
 <CAK9Gx1fUrrsPTug5n0fNGEkJ=_J8L2JAqubZtNNuNL9ZaS3KxQ@mail.gmail.com>
 <CAK9Gx1czsrxtuVUo_sCbY6LR3W2wTLbgOo6TOPWZY0vEyKhtUQ@mail.gmail.com>
 <5BBE1D8D.6040806@oracle.com>
 <CAK9Gx1c81CEgz4_EnsLeP0WXu82rfsWed-iYWqhtn12fJy+wrA@mail.gmail.com>
 <CAKjRUT61HwGRuUnU6D8WA8C1nMQr9tBVuKyLtAgyHtNKJJU=hw@mail.gmail.com>
 <CAK9Gx1dvB=rBoN99zUewSBGNjpthoBQi+AyzmQbFnv-cE7wY2Q@mail.gmail.com>
 <a7abd67d-b72c-ceb1-7d7e-78df32600394@oracle.com>
 <CAKjRUT7Odx3xaYykCRPbWLTHqc6AEV59wHjeQGCp4_41FYNvSQ@mail.gmail.com>
Message-ID: <CAKjRUT6VUUPg+OqCgQbJWCBoaqyYYU72CY7iQadWh0zWpj0=Dg@mail.gmail.com>

Phil,
I looked at the hostpot in
src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c (75%
cpu time) and its sort algorithm looks like an insertion sort ...
If you could give me some explanations (or documentation), I could try
optimizing this method.

Do you know if it uses an Active Edge Table (AET) or it traverses all
segments every time ?
i.e. segmentTable contains only ACTIVE segments or all ?

static jboolean
ShapeSINextSpan(void *state, jint spanbox[])
{
    pathData *pd = (pathData *)state;
    int lo, cur, new, hi;
    int num = pd->numSegments;
    jint x0, x1, y0, err;
    jint loy;
    int ret = JNI_FALSE;
    segmentData **segmentTable;
    segmentData *seg;

    if (pd->state != STATE_SPAN_STARTED) {
        if (!initSegmentTable(pd)) {
            /* REMIND: - throw exception? */
            pd->lowSegment = num;
            return JNI_FALSE;
        }
    }

    lo = pd->lowSegment;
    cur = pd->curSegment;
    hi = pd->hiSegment;
    num = pd->numSegments;
    loy = pd->loy;
    segmentTable = pd->segmentTable;

    while (lo < num) {
        if (cur < hi) {
            seg = segmentTable[cur];
            x0 = seg->curx;
            if (x0 >= pd->hix) {
                cur = hi;
                continue;
            }
            if (x0 < pd->lox) {
                x0 = pd->lox;
            }

            if (pd->evenodd) {
                cur += 2;
                if (cur <= hi) {
                    x1 = segmentTable[cur - 1]->curx;
                } else {
                    x1 = pd->hix;
                }
            } else {
                int wind = seg->windDir;
                cur++;

                while (JNI_TRUE) {
                    if (cur >= hi) {
                        x1 = pd->hix;
                        break;
                    }
                    seg = segmentTable[cur++];
                    wind += seg->windDir;
                    if (wind == 0) {
                        x1 = seg->curx;
                        break;
                    }
                }
            }

            if (x1 > pd->hix) {
                x1 = pd->hix;
            }
            if (x1 <= x0) {
                continue;
            }
            spanbox[0] = x0;
            spanbox[1] = loy;
            spanbox[2] = x1;
            spanbox[3] = loy + 1;
            ret = JNI_TRUE;
            break;
        }

        if (++loy >= pd->hiy) {
            lo = cur = hi = num;
            break;
        }

        /* Go through active segments and toss which end "above" loy */
        cur = new = hi;
        while (--cur >= lo) {
            seg = segmentTable[cur];
            if (seg->lasty > loy) {
                segmentTable[--new] = seg;
            }
        }

        lo = new;
        if (lo == hi && lo < num) {
            /* The current list of segments is empty so we need to
             * jump to the beginning of the next set of segments.
             * Since the segments are not clipped to the output
             * area we need to make sure we don't jump "backwards"
             */
            seg = segmentTable[lo];
            if (loy < seg->cury) {
                loy = seg->cury;
            }
        }

        /* Go through new segments and accept any which start "above" loy */
        while (hi < num && segmentTable[hi]->cury <= loy) {
            hi++;
        }

        /* Update and sort the active segments by x0 */
        for (cur = lo; cur < hi; cur++) {
            seg = segmentTable[cur];

            /* First update the x0, y0 of the segment */
            x0 = seg->curx;
            y0 = seg->cury;
            err = seg->error;
            if (++y0 == loy) {
                x0 += seg->bumpx;
                err += seg->bumperr;
                x0 -= (err >> 31);
                err &= ERRSTEP_MAX;
            } else {
                jlong steps = loy;
                steps -= y0 - 1;
                y0 = loy;
                x0 += (jint) (steps * seg->bumpx);
                steps = err + (steps * seg->bumperr);
                x0 += (jint) (steps >> 31);
                err = ((jint) steps) & ERRSTEP_MAX;
            }
            seg->curx = x0;
            seg->cury = y0;
            seg->error = err;








*            /* Then make sure the segment is sorted by x0 */
for (new = cur; new > lo; new--) {                segmentData *seg2 =
segmentTable[new - 1];                if (seg2->curx <= x0)
{                    break;                }
segmentTable[new] = seg2;            }*
            segmentTable[new] = seg;
        }
        cur = lo;
    }

    pd->lowSegment = lo;
    pd->hiSegment = hi;
    pd->curSegment = cur;
    pd->loy = loy;
    return ret;
}

Cheers,
Laurent

Le ven. 12 oct. 2018 ? 07:04, Laurent Bourg?s <bourges.laurent at gmail.com> a
?crit :

> Phil,
>
> It reminds me I have rewritten in Marlin renderer the crossing sort at
> every scanline.
> Pisces was using a trivial insertion sort but it became very slow when the
> crossing count is large.
> I adopted a special merge sort as crossings are mostly ordered: big win.
>
> What sort algo is in action in drawPolyLine ?
>
> Cheers,
> Laurent
>
> Le ven. 12 oct. 2018 ? 01:15, Phil Race <philip.race at oracle.com> a ?crit :
>
>>
>> In my previous email I was asking only about the "older" system,
>> precisely because as you confirm below, I wanted to know that
>> it was operating on an unscaled graphics.
>>
>> It is being triggered by the scale. If you add :
>> graphics.scale(1.25, 1.25)
>> in your application and run on 8 you'll see the window size is
>> not changed but the contents are and the test now runs slowly
>> like the JDK 9+ case.
>>
>> I think most primitives (text, images, fills, gradients, untransformed
>> rectangle drawing) will be only slightly slower. The same if
>> you were drawing anti-aliased lines - they are going to be slow already
>> by comparison.
>>
>> A few similar primitives (drawArc, drawOval, drawPolygon ..) may be
>> similarly
>> affected but drawPolyLine even has dedicated loops for single pixel wide
>> lines
>> so may be the most affected when these loops can't be used.
>>
>> So this is a kind of worse case difference. Untransformed, aliased lines
>> are super fast.
>> Once you do anything like add anti-aliasing or a transform, they get
>> slower.
>>
>> Note: hidpi does not mean that acceleration is "turned off", rather that
>> some operations can no longer be sent to the accelerated pipeline, either
>> it doesn't support that mode, or we haven't implemented the necessary code
>> to invoke it for that mode.
>>
>> In Peter's case on Intel there will be no acceleration, since we do not
>> enable D3D
>> on Intel graphics cards. But on my system the time is identical whether
>> I use D3D or not.
>>
>> But there is something else going on here too.
>> Peter's test use 2^16 line segments.
>>
>> On my windows system at 1.25 scale, this takes 55 seconds to run.
>> But 2^15 line segments completes in 10 seconds.
>> So 2 x the no. of lines takes approx 5 times as long to run ..
>>
>> I have a modified version of Peter's program which breaks the polyline
>> array
>> into subarrays which get passed to multiple calls to drawPolyline.
>> It misses joining the last point in ARR[N] to the first point in
>> ARR[N+1] but
>> I think that should not make much difference but if someone wants to use
>> that in a real app they'll need to handle it.
>>
>> What I see is that using the smaller arrays makes a big difference.
>>
>> So instead of 60 seconds to draw one 65,536 element polyline, to
>> draw 64 polylines of 1,024 elements takes just 1.1 seconds.
>> Still not 0.05 but better.
>>  From what I can see it is being turned into a huge GeneralPath and
>> rendered as a Shape. Multiple smaller shapes perform better.
>> Perhaps we can add a loop that is specific to polygons that will handle
>> this better, but that isn't likely to be jumped on .. and obviously
>> it will never be *as* fast as narrow lines.
>>
>> -phil.
>>
>>
>>
>> On 10/11/2018 04:26 AM, Peter Hull wrote:
>> > Hi Laurent,
>> > Thanks for the detailed explanation. I quickly checked on the older
>> > Windows system and the Java 11 window was the same size as the Java 8
>> > one, implying no scaling was going on (I guess just because it has a
>> > lower resolution monitor) - so that confirms your hypothesis.
>> >
>> > If I use -Dsun.java2d.uiScale=1.0 that's OK for my laptop, it doesn't
>> > matter if the window is a bit small. However I believe some higher end
>> > systems have much higher scaling factors (2x, 3x?). Is there a general
>> > way to specify a 1px line regardless of scaling, because in my case I
>> > don't mind too much if it's a 'hair-line'?
>> >
>> > By the way, my actual application doesn't have 65000 lines but it
>> > draws 3 graphs with about 3000 points, which makes it noticeably slow
>> > when resizing the Window. I suppose I should look into cutting down
>> > the number of points somehow...
>> >
>> > Pete
>>
>>

-- 
-- 
Laurent Bourg?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181012/f911ba07/attachment-0001.html>

From Bill.York at mathworks.com  Fri Oct 12 11:18:14 2018
From: Bill.York at mathworks.com (Bill York)
Date: Fri, 12 Oct 2018 11:18:14 +0000
Subject: [OpenJDK 2D-Dev] Crash in CGraphicsDevice.m
In-Reply-To: <4c6e82c6-b5c8-a2ca-2fc4-6ecb32b96ecb@oracle.com>
References: <BE0719D1-DD45-4B25-8254-2EB83FED8149@mathworks.com>
 <4c6e82c6-b5c8-a2ca-2fc4-6ecb32b96ecb@oracle.com>
Message-ID: <12F1F1D6-F6F0-486E-99A3-E0AFC32BC8A9@mathworks.com>

Excellent. That looks like the same bug. Note that it also affects JDK8.

Bill

?On 10/11/18, 5:43 PM, "Sergey Bylokhov" <Sergey.Bylokhov at oracle.com> wrote:

    Hi, Bill.
    
    The similar bug was reported recently:
    https://bugs.openjdk.java.net/browse/JDK-8211992
    
    The root cause is how we use CoreGraphics display ID. This identifier can become non-valid at any time therefore methods, which is using this id should be ready to it.
    
    And this bug found a few places which does not take care about the rule above.
    
    I am working on the fix for jdk12.
    
    On 10/10/2018 08:45, Bill York wrote:
    > 2d-dev folks,
    > 
    > I work on a product called MATLAB and we have about 60 reports from customers on Mac related to a crash in CGraphicsDevice.m
    > 
    > Please let  me know if this is the right way to report a crash and discuss getting it resolved.
    > 
    > Here are the details:
    > 
    > CGraphicsDevice.m is a native file in support of Java drawing and gets called from Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode
    > 
    > While I can?t reproduce the problem, it looks like the display pointer is becoming invalid for a time when the user?s laptop opens or closes.
    > 
    > Looking at this source code:
    > 
    > http://cr.openjdk.java.net/~serb/8000629/webrev.08/src/macosx/native/sun/awt/CGraphicsDevice.m.html
    > 
    > I see a direct call to CFStringCompare without a check for a NULL CFStringRef.
    > 
    >   * (CFStringCompare(mode, CFSTR(kIO30BitDirectPixels), kCFCompareCaseInsensitive) == kCFCompareEqualTo)
    > 
    > I believe if this code returned 0, the crash would not occur though there may be some other cleanup in the surrounding call frames.
    > 
    > Bill
    > 
    
    
    -- 
    Best regards, Sergey.
    
    


From philip.race at oracle.com  Fri Oct 12 14:36:58 2018
From: philip.race at oracle.com (Philip Race)
Date: Fri, 12 Oct 2018 07:36:58 -0700
Subject: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11
In-Reply-To: <CAKjRUT6VUUPg+OqCgQbJWCBoaqyYYU72CY7iQadWh0zWpj0=Dg@mail.gmail.com>
References: <CAK9Gx1fx=w29r1BSCYwBsxqe6SMKTMpQPj30xb0-5F+0nsudMg@mail.gmail.com>
 <CAKjRUT6UqCp0aLefOy_fD86nJP40qNNJ7RqoRvZ-khsPpvvKZg@mail.gmail.com>
 <CAK9Gx1dHXTm_ctFjh0F+Mh3bMbkJ2wXhABXS7GJhCghwe_06Zw@mail.gmail.com>
 <CAKjRUT6fe+SLCO0aHXQm76CrLZJfxfK6vG6d5ZXZaB4ocEm-GA@mail.gmail.com>
 <CAK9Gx1fUrrsPTug5n0fNGEkJ=_J8L2JAqubZtNNuNL9ZaS3KxQ@mail.gmail.com>
 <CAK9Gx1czsrxtuVUo_sCbY6LR3W2wTLbgOo6TOPWZY0vEyKhtUQ@mail.gmail.com>
 <5BBE1D8D.6040806@oracle.com>
 <CAK9Gx1c81CEgz4_EnsLeP0WXu82rfsWed-iYWqhtn12fJy+wrA@mail.gmail.com>
 <CAKjRUT61HwGRuUnU6D8WA8C1nMQr9tBVuKyLtAgyHtNKJJU=hw@mail.gmail.com>
 <CAK9Gx1dvB=rBoN99zUewSBGNjpthoBQi+AyzmQbFnv-cE7wY2Q@mail.gmail.com>
 <a7abd67d-b72c-ceb1-7d7e-78df32600394@oracle.com>
 <CAKjRUT7Odx3xaYykCRPbWLTHqc6AEV59wHjeQGCp4_41FYNvSQ@mail.gmail.com>
 <CAKjRUT6VUUPg+OqCgQbJWCBoaqyYYU72CY7iQadWh0zWpj0=Dg@mail.gmail.com>
Message-ID: <5BC0B18A.90300@oracle.com>

If there are no comments in the source, then there is no documentation :-(
Reverse engineering/studying the code is what we'd have to do if that were
the approach to be taken here.

-phil.

On 10/12/18, 2:18 AM, Laurent Bourg?s wrote:
> Phil,
> I looked at the hostpot in 
> src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c 
> (75% cpu time) and its sort algorithm looks like an insertion sort ...
> If you could give me some explanations (or documentation), I could try 
> optimizing this method.
>
> Do you know if it uses an Active Edge Table (AET) or it traverses all 
> segments every time ?
> i.e. segmentTable contains only ACTIVE segments or all ?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181012/cebf1bef/attachment.html>

From peterhull90 at gmail.com  Fri Oct 12 14:51:38 2018
From: peterhull90 at gmail.com (Peter Hull)
Date: Fri, 12 Oct 2018 15:51:38 +0100
Subject: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11
In-Reply-To: <5BC0B18A.90300@oracle.com>
References: <CAK9Gx1fx=w29r1BSCYwBsxqe6SMKTMpQPj30xb0-5F+0nsudMg@mail.gmail.com>
 <CAKjRUT6UqCp0aLefOy_fD86nJP40qNNJ7RqoRvZ-khsPpvvKZg@mail.gmail.com>
 <CAK9Gx1dHXTm_ctFjh0F+Mh3bMbkJ2wXhABXS7GJhCghwe_06Zw@mail.gmail.com>
 <CAKjRUT6fe+SLCO0aHXQm76CrLZJfxfK6vG6d5ZXZaB4ocEm-GA@mail.gmail.com>
 <CAK9Gx1fUrrsPTug5n0fNGEkJ=_J8L2JAqubZtNNuNL9ZaS3KxQ@mail.gmail.com>
 <CAK9Gx1czsrxtuVUo_sCbY6LR3W2wTLbgOo6TOPWZY0vEyKhtUQ@mail.gmail.com>
 <5BBE1D8D.6040806@oracle.com>
 <CAK9Gx1c81CEgz4_EnsLeP0WXu82rfsWed-iYWqhtn12fJy+wrA@mail.gmail.com>
 <CAKjRUT61HwGRuUnU6D8WA8C1nMQr9tBVuKyLtAgyHtNKJJU=hw@mail.gmail.com>
 <CAK9Gx1dvB=rBoN99zUewSBGNjpthoBQi+AyzmQbFnv-cE7wY2Q@mail.gmail.com>
 <a7abd67d-b72c-ceb1-7d7e-78df32600394@oracle.com>
 <CAKjRUT7Odx3xaYykCRPbWLTHqc6AEV59wHjeQGCp4_41FYNvSQ@mail.gmail.com>
 <CAKjRUT6VUUPg+OqCgQbJWCBoaqyYYU72CY7iQadWh0zWpj0=Dg@mail.gmail.com>
 <5BC0B18A.90300@oracle.com>
Message-ID: <CAK9Gx1cd4HzE3fw-N6Z5_BBbKiXvMB5jWa2GvEtT1g--X2z+og@mail.gmail.com>

This has been given a Java bug number now: JDK-8212124
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8212124

I have been following the discussion here and I have a couple of
workarounds to try, which is great.

But, is there any more information you need from me? I'm always happy to help.

Thanks,
Pete

From Bill.York at mathworks.com  Fri Oct 12 18:46:40 2018
From: Bill.York at mathworks.com (Bill York)
Date: Fri, 12 Oct 2018 18:46:40 +0000
Subject: [OpenJDK 2D-Dev] Crash in CGraphicsDevice.m
In-Reply-To: <4c6e82c6-b5c8-a2ca-2fc4-6ecb32b96ecb@oracle.com>
References: <BE0719D1-DD45-4B25-8254-2EB83FED8149@mathworks.com>
 <4c6e82c6-b5c8-a2ca-2fc4-6ecb32b96ecb@oracle.com>
Message-ID: <786EC174-FD64-4AA8-9E98-1EE02BB16AEF@mathworks.com>

Thanks Sergey.

?On 10/11/18, 5:43 PM, "Sergey Bylokhov" <Sergey.Bylokhov at oracle.com> wrote:

    Hi, Bill.
    
    The similar bug was reported recently:
    https://bugs.openjdk.java.net/browse/JDK-8211992
    
    The root cause is how we use CoreGraphics display ID. This identifier can become non-valid at any time therefore methods, which is using this id should be ready to it.
    
    And this bug found a few places which does not take care about the rule above.
    
    I am working on the fix for jdk12.
    
    On 10/10/2018 08:45, Bill York wrote:
    > 2d-dev folks,
    > 
    > I work on a product called MATLAB and we have about 60 reports from customers on Mac related to a crash in CGraphicsDevice.m
    > 
    > Please let  me know if this is the right way to report a crash and discuss getting it resolved.
    > 
    > Here are the details:
    > 
    > CGraphicsDevice.m is a native file in support of Java drawing and gets called from Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode
    > 
    > While I can?t reproduce the problem, it looks like the display pointer is becoming invalid for a time when the user?s laptop opens or closes.
    > 
    > Looking at this source code:
    > 
    > http://cr.openjdk.java.net/~serb/8000629/webrev.08/src/macosx/native/sun/awt/CGraphicsDevice.m.html
    > 
    > I see a direct call to CFStringCompare without a check for a NULL CFStringRef.
    > 
    >   * (CFStringCompare(mode, CFSTR(kIO30BitDirectPixels), kCFCompareCaseInsensitive) == kCFCompareEqualTo)
    > 
    > I believe if this code returned 0, the crash would not occur though there may be some other cleanup in the surrounding call frames.
    > 
    > Bill
    > 
    
    
    -- 
    Best regards, Sergey.
    
    


From prasanta.sadhukhan at oracle.com  Sat Oct 13 03:52:59 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Sat, 13 Oct 2018 09:22:59 +0530
Subject: [OpenJDK 2D-Dev] [12] RFR JDK-8212040: Compilation error due to
 wrong usage of NSPrintJobDispositionValue in mac10.12
In-Reply-To: <88ad790e-a1d0-c65c-d6d2-b7ca0c57a082@oracle.com>
References: <88ad790e-a1d0-c65c-d6d2-b7ca0c57a082@oracle.com>
Message-ID: <1f98a511-487d-724d-479d-7fb9f69ef538@oracle.com>

Ping? Since this fix addresses build failure which will affect 
production, I guess this needs to go in asap.

Regards
Prasanta
On 11-Oct-18 1:39 PM, Prasanta Sadhukhan wrote:
> Hi All,
>
> Please review a build issue fix for usage of 
> NSPrintJobDispositionValue in JDK-8211055 
> <https://bugs.openjdk.java.net/browse/JDK-8211055>: Provide print to a 
> file (PDF) feature even when printer was not connected
> It seems that NSPrintJobDispositionValue is added in 10.13 sdk 
> [https://developer.apple.com/documentation/appkit/nsprintjobdispositionvalue?language=objc]
> so using it in 10.12 or lower cause build issue.
>
> Fix is to check for disposition value directly instead of storing in 
> variable.
> mach5 build is successful.
>
> Bug:https://bugs.openjdk.java.net/browse/JDK-8212040
> webrev: http://cr.openjdk.java.net/~psadhukhan/8212040/webrev/
>
> Regards
> Prasanta

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181013/3a2eeb1c/attachment.html>

From jayathirth.d.v at oracle.com  Sat Oct 13 04:43:15 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Sat, 13 Oct 2018 04:43:15 +0000 (UTC)
Subject: [OpenJDK 2D-Dev] [12] RFR JDK-8212040: Compilation error due to
 wrong usage of NSPrintJobDispositionValue in mac10.12
In-Reply-To: <88ad790e-a1d0-c65c-d6d2-b7ca0c57a082@oracle.com>
References: <88ad790e-a1d0-c65c-d6d2-b7ca0c57a082@oracle.com>
Message-ID: <b325b9fc-a3ff-40b3-81e5-9d69d4ed9790@default>

Hi Prasanta,

?

Changes are fine.

?

Thanks,

Jay

?

From: Prasanta Sadhukhan 
Sent: Thursday, October 11, 2018 1:40 PM
To: 2d-dev
Subject: [OpenJDK 2D-Dev] [12] RFR JDK-8212040: Compilation error due to wrong usage of NSPrintJobDispositionValue in mac10.12

?

Hi All,

Please review a build issue fix for usage of NSPrintJobDispositionValue in HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8211055"JDK-8211055: Provide print to a file (PDF) feature even when printer was not connected
It seems that NSPrintJobDispositionValue is added in 10.13 sdk [https://developer.apple.com/documentation/appkit/nsprintjobdispositionvalue?language=objc]
so using it in 10.12 or lower cause build issue.

Fix is to check for disposition value directly instead of storing in variable.
mach5 build is successful.

Bug:https://bugs.openjdk.java.net/browse/JDK-8212040
webrev: http://cr.openjdk.java.net/~psadhukhan/8212040/webrev/

Regards
Prasanta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181013/b76b6b37/attachment-0001.html>

From Sergey.Bylokhov at oracle.com  Tue Oct 16 01:11:25 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 15 Oct 2018 18:11:25 -0700
Subject: [OpenJDK 2D-Dev] [12] Review Request: 8211992
 GraphicsConfiguration.getDevice().getDisplayMode() causes JVM crash on Mac
Message-ID: <92a3b11d-6734-7aeb-0520-7ae0279d24a9@oracle.com>

Hello.
Please review the fix for jdk 12.

Bug: https://bugs.openjdk.java.net/browse/JDK-8211992
Webrev: http://cr.openjdk.java.net/~serb/8211992/webrev.00

Short description:
   The root cause is how we use CoreGraphics display ID. This identifier can become non-valid at any time therefore methods, which is using this id should be ready to it. And this bug found a few places which does not take care about the rule above.

Long description:
   In the CGraphicsDevice class we maintain the ID for the native screen. This ID usually changed when the user adds/removes monitors to the system. Since using invalid id can cause NULL result in the native code we tries to workaround it by two steps:

   Step (1) If the monitor is removed from the system, then we reassign its displayid to the primary screen. So if the user will holds the reference to this GDevice, it will use the MainDisplay. But note that if the user will remove the main screen again then the old screen, which were removed previously, will not be updated(but will use an invalid displayid).

   Step (2) Some of the native methods in CGraphicsDevice class are ready to NULL and provide some meaningful defaults, like 72 dpi. But some others methods are not ready for that, like nativeGetDisplayMode/etc.

Fix description:
  - I have minimized/dropped the usage of displayid outside of CGraphicsDevice class, in CRobot it was unused, and the code from CGraphicsConfig.m was moved to CGraphicsDevice.m.
  - In CGraphicsEnvironment class we now maintain the list of old devices, which is updated for all _displayReconfiguration events. This is the same implementation as on windows in Win32GraphicsEnvironment.java
  - I have added some default values to all native methods also. Just to cover the rare case when we call the method and displayid became invalid at the same moment.

-- 
Best regards, Sergey.

From philip.race at oracle.com  Tue Oct 16 06:40:48 2018
From: philip.race at oracle.com (Philip Race)
Date: Mon, 15 Oct 2018 23:40:48 -0700
Subject: [OpenJDK 2D-Dev] Setting the FreeType LCD filter
In-Reply-To: <a0c25274-0a73-da5a-d3df-1d1fec7947e2@oracle.com>
References: <f5ef2fa9-52bf-9799-a41f-134bce17276b@status6.com>
 <CAKjRUT4CtKjG=k3m08-6_58bjM_OaFR3-3xCj0c=k_yOmuGm_A@mail.gmail.com>
 <6fd0a68f-f9bf-b3b2-1ade-21a0ff3ead94@status6.com>
 <a0c25274-0a73-da5a-d3df-1d1fec7947e2@oracle.com>
Message-ID: <5BC587F0.7010807@oracle.com>

I intend to push this with myself & Laurent as reviewers.

OK by all ?

-phil.

On 10/11/18, 12:22 PM, Phil Race wrote:
> Very well done analysis of the options and very thorough testing of 
> the effects
> on the different libraries/platforms.
>
>
> > There are some alternatives to setting the filter:
> >   ? Bundle the FreeType library by default
>
> Although the build makes this easy to set as an option, we decided we 
> prefer to
> use the platform library on Linux - and Solaris for that matter - in 
> our releases.
>
> So setting this option is going to be needed for some years to come, 
> until
> even a Linux current release like Ubuntu 18.04 is obsolete.
>
> We can't re-use the OpenJavaFX bug ID, and surprisingly I can't find 
> an open
> bug on this for 2D. So I've submitted 
> https://bugs.openjdk.java.net/browse/JDK-8212071
>
> And I've attached John's images to the bug report and pasted his email 
> in there.
>
>
>
> -phil.
>
>
> On 10/11/2018 10:56 AM, John Neffenger wrote:
>> On 10/10/2018 11:15 AM, Laurent Bourg?s wrote:
>>> It looks awesome & promising.
>>
>> Thank you, Laurent, for looking into it so quickly!
>>
>>> PS: It is better to send plain text (long) email than sending 
>>> external links (github).
>>
>> Thanks for the tip. Right, Web pages and repositories can be deleted, 
>> so here it is, for the record ...
>>
>> The symptoms of the problem are the same as in the link below, but 
>> they appear in AWT and Swing applications instead of JavaFX 
>> applications.
>>
>>   JDK-8188810: Fonts are blurry on Ubuntu 16.04 and Debian 9
>>   https://bugs.openjdk.java.net/browse/JDK-8188810
>>
>> The description of the problem on the Java side follows.
>>
>> Synopsis: Reduce color fringes in FreeType subpixel rendering
>>
>> The text in Java applications often has severe color fringes when 
>> using OpenJDK on Ubuntu and other Debian-based distributions because 
>> the JDK fails to set the LCD filter. Adding two lines of code to the 
>> file freetypeScaler.c fixed the problem in my tests, without any 
>> regression errors for other Linux distributions. The patch is 
>> attached to this message as the file freetypeScaler.diff.
>>
>> There are some alternatives to setting the filter:
>>
>>   ? Bundle the FreeType library by default and always use the new 
>> Harmony subpixel rendering technique. This option removes the 
>> uncertainty in the library at the expense of an additional 4.6 
>> megabytes to the installed size ? an increase of less than one 
>> percent. OpenJDK 12 even includes the latest FreeType 2.9.1, a newer 
>> version than the one found on most systems.
>>
>>   ? Wait another year and see what changes are made to FreeType, if 
>> any, when the ClearType patents expire. This option, though, doesn?t 
>> solve the problem that users of Ubuntu and other Debian-based 
>> distributions have now.
>>
>> The problem originates in decisions made by the developers of 
>> FreeType, Debian, Fedora, and OpenJDK concerning the Microsoft 
>> ClearType patents [1].
>>
>>   ? In 2007, FreeType 2.3.0 added a compiler configuration macro to 
>> the file ftoption.h named FT_CONFIG_OPTION_SUBPIXEL_RENDERING. If 
>> defined, the FreeType library includes patented ClearType techniques 
>> in its subpixel rendering.
>>
>>     But there?s a catch. When the ClearType methods are enabled, the 
>> subpixel rendering is not filtered, which results in severe color 
>> fringes. Clients of the FreeType library must make an explicit call 
>> to the function FT_Library_SetLcdFilter to apply color filtering. The 
>> filter was disabled by default, explained one of its authors, ?to 
>> avoid major surprises to existing clients, including libXft and Cairo 
>> which already perform some wacky color filtering on top of FreeType.?
>>
>>   ? In 2009, Debian created a patch to FreeType 2.3.9, named 
>> enable-subpixel-rendering.patch, that defines the macro and enables 
>> ClearType-style rendering. The change log states, ?This is considered 
>> no more or less evil than the bytecode interpreter which we also 
>> enable.? Ubuntu, based on Debian, applies the patch as well. Fedora 
>> created the same patch in 2007, named 
>> freetype-2.3.0-enable-spr.patch, but does not apply the patch by 
>> default.
>>
>>   ? In 2017, FreeType 2.8.1 included a new subpixel rendering 
>> technique, called Harmony, that is nearly identical in output to the 
>> ClearType technique but uses a different algorithm, avoiding the 
>> patents. FreeType now uses Harmony subpixel rendering when the 
>> ClearType methods are disabled, with no need for clients to set the 
>> LCD filter. (This would have been a good time for Debian to remove 
>> its subpixel rendering patch.) The latest Fedora Workstation 28 runs 
>> FreeType 2.8.0, which does not include Harmony.
>>
>>   ? In 2019, the Microsoft ClearType patents expire.
>>
>> So now we have two variants of the FreeType library: one that 
>> requires a function call to set the LCD filter in Ubuntu and other 
>> distributions based on Debian, and another that doesn?t require the 
>> function call in Red Hat Enterprise Linux, Oracle Linux, and other 
>> distributions based on Fedora.
>>
>> To demonstrate the problem, I built four versions of the JDK from the 
>> latest OpenJDK sources. I built a version that uses the system 
>> FreeType library and another that uses the bundled FreeType library. 
>> Then I changed the OpenJDK code to set the default LCD filter and 
>> built the two versions again. The four builds were named:
>>
>>   jdk-12-system-lcdnone
>>   jdk-12-system-lcddefault
>>   jdk-12-bundled-lcdnone
>>   jdk-12-bundled-lcddefault
>>
>> The system library is FreeType 2.8.1 in Ubuntu 18.04.1 LTS, which has 
>> the Debian patch applied (ClearType methods enabled), while the 
>> bundled library is FreeType 2.9.1 in OpenJDK 12, which uses the 
>> library default (ClearType methods disabled). I wrote a simple Java 
>> Swing application called FontDemo [2] that displays two text areas 
>> with the Adobe Source Code Pro font [3] in TTF and OTF formats (the 
>> latest non-variable download).
>>
>> The results are shown in the two images attached to this message:
>>
>>   fontdemo.png
>>     Three screenshots of the FontDemo program
>>
>>   fontdemo-detail.png
>>     Details from the screenshots scaled by 800 percent
>>
>> When using the Ubuntu system FreeType library, setting the LCD filter 
>> is critical. The screenshots show the ClearType-style rendering 
>> without setting the LCD filter, and after adding the change to set 
>> the filter. The ClearType configuration macro is defined in the 
>> Ubuntu build of FreeType, so the function to set the filter returns 
>> success (0) when called and applies color filtering.
>>
>> When using the OpenJDK bundled FreeType library, setting the LCD 
>> filter does nothing. The screenshots show the FreeType Harmony 
>> rendering, which is the same whether or not the LCD filter is set. 
>> The ClearType configuration macro is not defined in the OpenJDK build 
>> of FreeType, so the function to set the filter returns 
>> FT_Err_Unimplemented_Feature (7) when called and does nothing.
>>
>> The test system I used is a QEMU/KVM guest virtual machine running 
>> Ubuntu 18.04.1 LTS (Bionic Beaver) with the details shown below. The 
>> display is a 27-inch Dell UltraSharp U2717D monitor with a resolution 
>> of 2560 ? 1440 pixels at 109 pixels per inch.
>>
>> ubuntu at bionic:~$ uname -a
>> Linux bionic 4.15.0-36-generic #39-Ubuntu SMP
>>   Mon Sep 24 16:19:09 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
>>
>> ubuntu at bionic:~$ ldd --version
>> ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27
>>
>> ubuntu at bionic:~$ getconf GNU_LIBPTHREAD_VERSION
>> NPTL 2.27
>>
>> ubuntu at bionic:~$ $HOME/opt/jdk-12-system-lcdnone/bin/java -version
>> openjdk version "12-internal" 2019-03-19
>> OpenJDK Runtime Environment (build 12-internal+0-adhoc.ubuntu.jdk)
>> OpenJDK 64-Bit Server VM (build 12-internal+0-adhoc.ubuntu.jdk, mixed 
>> mode)
>>
>> Below are the full test results using five versions of FreeType built 
>> first with the ClearType methods disabled (the default) and then 
>> again with them enabled. I ran all 10 libraries under OpenJDK 12, 
>> first with no LCD filter and then again after adding the code to set 
>> the default LCD filter.
>>
>> No LCD Filter
>>
>> 2008 FreeType 2.3.5 (libfreetype.so.6.3.16) in Ubuntu 8.04 LTS
>>     ClearType Off: Grayscale, ClearType On: Mild fringes
>>
>> 2014 FreeType 2.5.2 (libfreetype.so.6.11.1) in Ubuntu 14.04 LTS
>>     ClearType Off: Grayscale, ClearType On: Severe fringes
>>
>> 2016 FreeType 2.6.1 (libfreetype.so.6.12.1) in Ubuntu 16.04 LTS
>>     ClearType Off: Grayscale, ClearType On: Severe fringes
>>
>> 2018 FreeType 2.8.1 (libfreetype.so.6.15.0) in Ubuntu 18.04 LTS
>>     ClearType Off: Harmony, ClearType On: Severe fringes
>>
>> 2019 FreeType 2.9.1 (libfreetype.so.6.16.1) in OpenJDK 12
>>     ClearType Off: Harmony, ClearType On: Severe fringes
>>
>> The OpenJDK does not set the FreeType LCD filter, so there are severe 
>> color fringes when using a FreeType library built with the ClearType 
>> methods enabled. The only reason the older FreeType 2.3.5 shows mild 
>> color fringes is because it uses full hinting, so the glyphs are 
>> simply too skinny to see their colors.
>>
>> Default LCD Filter
>>
>> 2008 FreeType 2.3.5 (libfreetype.so.6.3.16) in Ubuntu 8.04 LTS
>>     ClearType Off: Grayscale, ClearType On: ClearType filtered
>>
>> 2014 FreeType 2.5.2 (libfreetype.so.6.11.1) in Ubuntu 14.04 LTS
>>     ClearType Off: Grayscale, ClearType On: ClearType filtered
>>
>> 2016 FreeType 2.6.1 (libfreetype.so.6.12.1) in Ubuntu 16.04 LTS
>>     ClearType Off: Grayscale, ClearType On: ClearType filtered
>>
>> 2018 FreeType 2.8.1 (libfreetype.so.6.15.0) in Ubuntu 18.04 LTS
>>     ClearType Off: Harmony, ClearType On: ClearType filtered
>>
>> 2019 FreeType 2.9.1 (libfreetype.so.6.16.1) in OpenJDK 12
>>     ClearType Off: Harmony, ClearType On: ClearType filtered
>>
>> After changing the OpenJDK to set the default LCD filter, there is no 
>> version of the FreeType library that shows the severe color fringes. 
>> Note that Fedora Workstation 28 includes FreeType 2.8.0 with the 
>> ClearType methods disabled, so it displays grayscale anti-aliasing 
>> for the OpenJDK whether it sets the LCD filter or not. (FreeType 
>> 2.8.0 does not include Harmony.)
>>
>> For background information on LCD filters see Section 2.2.1 [4] of 
>> The Raster Tragedy at Low-Resolution, which has an interactive 
>> demonstration of the filters used in ClearType (Microsoft), CoolType 
>> (Adobe), FreeType (open source), and Quartz 2D (Apple). Hover your 
>> mouse over each of the samples in the illustration to remove the filter.
>>
>> Below is the relevant section of the file ftoption.h in FreeType 
>> 2.9.1 bundled with OpenJDK 12, edited for formatting:
>>
>> java.desktop/share/native/libfreetype/include/freetype/config/ftoption.h
>>
>> /*
>> Uncomment the line below if you want to activate LCD rendering
>> technology similar to ClearType in this build of the library. This
>> technology triples the resolution in the direction color subpixels.
>> To mitigate color fringes inherent to this technology, you also need
>> to explicitly set up LCD filtering.
>>
>> Note that this feature is covered by several Microsoft patents
>> and should not be activated in any default build of the library.
>> When this macro is not defined, FreeType offers alternative LCD
>> rendering technology that produces excellent output without LCD
>> filtering.
>> */
>> /* #define FT_CONFIG_OPTION_SUBPIXEL_RENDERING */
>>
>> [1] http://david.freetype.org/cleartype-patents.html
>> [2] 
>> https://github.com/jgneff/openjdk-freetype/blob/master/src/org/status6/FontDemo.java
>> [3] https://github.com/adobe-fonts/source-code-pro
>> [4] http://rastertragedy.com/RTRCh2.htm#Sec21
>

From bourges.laurent at gmail.com  Tue Oct 16 07:00:57 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Tue, 16 Oct 2018 09:00:57 +0200
Subject: [OpenJDK 2D-Dev] Setting the FreeType LCD filter
In-Reply-To: <5BC587F0.7010807@oracle.com>
References: <f5ef2fa9-52bf-9799-a41f-134bce17276b@status6.com>
 <CAKjRUT4CtKjG=k3m08-6_58bjM_OaFR3-3xCj0c=k_yOmuGm_A@mail.gmail.com>
 <6fd0a68f-f9bf-b3b2-1ade-21a0ff3ead94@status6.com>
 <a0c25274-0a73-da5a-d3df-1d1fec7947e2@oracle.com>
 <5BC587F0.7010807@oracle.com>
Message-ID: <CAKjRUT5t+db0u=-MD9V1C+KD+6gW_n+irEv5euXGbrud=Qggrg@mail.gmail.com>

Phil,
I tested John's patch sucessfully, it is complicated to write a jtreg
Test...

OK for me as it is.

Laurent

Le mar. 16 oct. 2018 ? 08:40, Philip Race <philip.race at oracle.com> a ?crit :

> I intend to push this with myself & Laurent as reviewers.
>
> OK by all ?
>
> -phil.
>
> On 10/11/18, 12:22 PM, Phil Race wrote:
> > Very well done analysis of the options and very thorough testing of
> > the effects
> > on the different libraries/platforms.
> >
> >
> > > There are some alternatives to setting the filter:
> > >   ? Bundle the FreeType library by default
> >
> > Although the build makes this easy to set as an option, we decided we
> > prefer to
> > use the platform library on Linux - and Solaris for that matter - in
> > our releases.
> >
> > So setting this option is going to be needed for some years to come,
> > until
> > even a Linux current release like Ubuntu 18.04 is obsolete.
> >
> > We can't re-use the OpenJavaFX bug ID, and surprisingly I can't find
> > an open
> > bug on this for 2D. So I've submitted
> > https://bugs.openjdk.java.net/browse/JDK-8212071
> >
> > And I've attached John's images to the bug report and pasted his email
> > in there.
> >
> >
> >
> > -phil.
> >
> >
> > On 10/11/2018 10:56 AM, John Neffenger wrote:
> >> On 10/10/2018 11:15 AM, Laurent Bourg?s wrote:
> >>> It looks awesome & promising.
> >>
> >> Thank you, Laurent, for looking into it so quickly!
> >>
> >>> PS: It is better to send plain text (long) email than sending
> >>> external links (github).
> >>
> >> Thanks for the tip. Right, Web pages and repositories can be deleted,
> >> so here it is, for the record ...
> >>
> >> The symptoms of the problem are the same as in the link below, but
> >> they appear in AWT and Swing applications instead of JavaFX
> >> applications.
> >>
> >>   JDK-8188810: Fonts are blurry on Ubuntu 16.04 and Debian 9
> >>   https://bugs.openjdk.java.net/browse/JDK-8188810
> >>
> >> The description of the problem on the Java side follows.
> >>
> >> Synopsis: Reduce color fringes in FreeType subpixel rendering
> >>
> >> The text in Java applications often has severe color fringes when
> >> using OpenJDK on Ubuntu and other Debian-based distributions because
> >> the JDK fails to set the LCD filter. Adding two lines of code to the
> >> file freetypeScaler.c fixed the problem in my tests, without any
> >> regression errors for other Linux distributions. The patch is
> >> attached to this message as the file freetypeScaler.diff.
> >>
> >> There are some alternatives to setting the filter:
> >>
> >>   ? Bundle the FreeType library by default and always use the new
> >> Harmony subpixel rendering technique. This option removes the
> >> uncertainty in the library at the expense of an additional 4.6
> >> megabytes to the installed size ? an increase of less than one
> >> percent. OpenJDK 12 even includes the latest FreeType 2.9.1, a newer
> >> version than the one found on most systems.
> >>
> >>   ? Wait another year and see what changes are made to FreeType, if
> >> any, when the ClearType patents expire. This option, though, doesn?t
> >> solve the problem that users of Ubuntu and other Debian-based
> >> distributions have now.
> >>
> >> The problem originates in decisions made by the developers of
> >> FreeType, Debian, Fedora, and OpenJDK concerning the Microsoft
> >> ClearType patents [1].
> >>
> >>   ? In 2007, FreeType 2.3.0 added a compiler configuration macro to
> >> the file ftoption.h named FT_CONFIG_OPTION_SUBPIXEL_RENDERING. If
> >> defined, the FreeType library includes patented ClearType techniques
> >> in its subpixel rendering.
> >>
> >>     But there?s a catch. When the ClearType methods are enabled, the
> >> subpixel rendering is not filtered, which results in severe color
> >> fringes. Clients of the FreeType library must make an explicit call
> >> to the function FT_Library_SetLcdFilter to apply color filtering. The
> >> filter was disabled by default, explained one of its authors, ?to
> >> avoid major surprises to existing clients, including libXft and Cairo
> >> which already perform some wacky color filtering on top of FreeType.?
> >>
> >>   ? In 2009, Debian created a patch to FreeType 2.3.9, named
> >> enable-subpixel-rendering.patch, that defines the macro and enables
> >> ClearType-style rendering. The change log states, ?This is considered
> >> no more or less evil than the bytecode interpreter which we also
> >> enable.? Ubuntu, based on Debian, applies the patch as well. Fedora
> >> created the same patch in 2007, named
> >> freetype-2.3.0-enable-spr.patch, but does not apply the patch by
> >> default.
> >>
> >>   ? In 2017, FreeType 2.8.1 included a new subpixel rendering
> >> technique, called Harmony, that is nearly identical in output to the
> >> ClearType technique but uses a different algorithm, avoiding the
> >> patents. FreeType now uses Harmony subpixel rendering when the
> >> ClearType methods are disabled, with no need for clients to set the
> >> LCD filter. (This would have been a good time for Debian to remove
> >> its subpixel rendering patch.) The latest Fedora Workstation 28 runs
> >> FreeType 2.8.0, which does not include Harmony.
> >>
> >>   ? In 2019, the Microsoft ClearType patents expire.
> >>
> >> So now we have two variants of the FreeType library: one that
> >> requires a function call to set the LCD filter in Ubuntu and other
> >> distributions based on Debian, and another that doesn?t require the
> >> function call in Red Hat Enterprise Linux, Oracle Linux, and other
> >> distributions based on Fedora.
> >>
> >> To demonstrate the problem, I built four versions of the JDK from the
> >> latest OpenJDK sources. I built a version that uses the system
> >> FreeType library and another that uses the bundled FreeType library.
> >> Then I changed the OpenJDK code to set the default LCD filter and
> >> built the two versions again. The four builds were named:
> >>
> >>   jdk-12-system-lcdnone
> >>   jdk-12-system-lcddefault
> >>   jdk-12-bundled-lcdnone
> >>   jdk-12-bundled-lcddefault
> >>
> >> The system library is FreeType 2.8.1 in Ubuntu 18.04.1 LTS, which has
> >> the Debian patch applied (ClearType methods enabled), while the
> >> bundled library is FreeType 2.9.1 in OpenJDK 12, which uses the
> >> library default (ClearType methods disabled). I wrote a simple Java
> >> Swing application called FontDemo [2] that displays two text areas
> >> with the Adobe Source Code Pro font [3] in TTF and OTF formats (the
> >> latest non-variable download).
> >>
> >> The results are shown in the two images attached to this message:
> >>
> >>   fontdemo.png
> >>     Three screenshots of the FontDemo program
> >>
> >>   fontdemo-detail.png
> >>     Details from the screenshots scaled by 800 percent
> >>
> >> When using the Ubuntu system FreeType library, setting the LCD filter
> >> is critical. The screenshots show the ClearType-style rendering
> >> without setting the LCD filter, and after adding the change to set
> >> the filter. The ClearType configuration macro is defined in the
> >> Ubuntu build of FreeType, so the function to set the filter returns
> >> success (0) when called and applies color filtering.
> >>
> >> When using the OpenJDK bundled FreeType library, setting the LCD
> >> filter does nothing. The screenshots show the FreeType Harmony
> >> rendering, which is the same whether or not the LCD filter is set.
> >> The ClearType configuration macro is not defined in the OpenJDK build
> >> of FreeType, so the function to set the filter returns
> >> FT_Err_Unimplemented_Feature (7) when called and does nothing.
> >>
> >> The test system I used is a QEMU/KVM guest virtual machine running
> >> Ubuntu 18.04.1 LTS (Bionic Beaver) with the details shown below. The
> >> display is a 27-inch Dell UltraSharp U2717D monitor with a resolution
> >> of 2560 ? 1440 pixels at 109 pixels per inch.
> >>
> >> ubuntu at bionic:~$ uname -a
> >> Linux bionic 4.15.0-36-generic #39-Ubuntu SMP
> >>   Mon Sep 24 16:19:09 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
> >>
> >> ubuntu at bionic:~$ ldd --version
> >> ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27
> >>
> >> ubuntu at bionic:~$ getconf GNU_LIBPTHREAD_VERSION
> >> NPTL 2.27
> >>
> >> ubuntu at bionic:~$ $HOME/opt/jdk-12-system-lcdnone/bin/java -version
> >> openjdk version "12-internal" 2019-03-19
> >> OpenJDK Runtime Environment (build 12-internal+0-adhoc.ubuntu.jdk)
> >> OpenJDK 64-Bit Server VM (build 12-internal+0-adhoc.ubuntu.jdk, mixed
> >> mode)
> >>
> >> Below are the full test results using five versions of FreeType built
> >> first with the ClearType methods disabled (the default) and then
> >> again with them enabled. I ran all 10 libraries under OpenJDK 12,
> >> first with no LCD filter and then again after adding the code to set
> >> the default LCD filter.
> >>
> >> No LCD Filter
> >>
> >> 2008 FreeType 2.3.5 (libfreetype.so.6.3.16) in Ubuntu 8.04 LTS
> >>     ClearType Off: Grayscale, ClearType On: Mild fringes
> >>
> >> 2014 FreeType 2.5.2 (libfreetype.so.6.11.1) in Ubuntu 14.04 LTS
> >>     ClearType Off: Grayscale, ClearType On: Severe fringes
> >>
> >> 2016 FreeType 2.6.1 (libfreetype.so.6.12.1) in Ubuntu 16.04 LTS
> >>     ClearType Off: Grayscale, ClearType On: Severe fringes
> >>
> >> 2018 FreeType 2.8.1 (libfreetype.so.6.15.0) in Ubuntu 18.04 LTS
> >>     ClearType Off: Harmony, ClearType On: Severe fringes
> >>
> >> 2019 FreeType 2.9.1 (libfreetype.so.6.16.1) in OpenJDK 12
> >>     ClearType Off: Harmony, ClearType On: Severe fringes
> >>
> >> The OpenJDK does not set the FreeType LCD filter, so there are severe
> >> color fringes when using a FreeType library built with the ClearType
> >> methods enabled. The only reason the older FreeType 2.3.5 shows mild
> >> color fringes is because it uses full hinting, so the glyphs are
> >> simply too skinny to see their colors.
> >>
> >> Default LCD Filter
> >>
> >> 2008 FreeType 2.3.5 (libfreetype.so.6.3.16) in Ubuntu 8.04 LTS
> >>     ClearType Off: Grayscale, ClearType On: ClearType filtered
> >>
> >> 2014 FreeType 2.5.2 (libfreetype.so.6.11.1) in Ubuntu 14.04 LTS
> >>     ClearType Off: Grayscale, ClearType On: ClearType filtered
> >>
> >> 2016 FreeType 2.6.1 (libfreetype.so.6.12.1) in Ubuntu 16.04 LTS
> >>     ClearType Off: Grayscale, ClearType On: ClearType filtered
> >>
> >> 2018 FreeType 2.8.1 (libfreetype.so.6.15.0) in Ubuntu 18.04 LTS
> >>     ClearType Off: Harmony, ClearType On: ClearType filtered
> >>
> >> 2019 FreeType 2.9.1 (libfreetype.so.6.16.1) in OpenJDK 12
> >>     ClearType Off: Harmony, ClearType On: ClearType filtered
> >>
> >> After changing the OpenJDK to set the default LCD filter, there is no
> >> version of the FreeType library that shows the severe color fringes.
> >> Note that Fedora Workstation 28 includes FreeType 2.8.0 with the
> >> ClearType methods disabled, so it displays grayscale anti-aliasing
> >> for the OpenJDK whether it sets the LCD filter or not. (FreeType
> >> 2.8.0 does not include Harmony.)
> >>
> >> For background information on LCD filters see Section 2.2.1 [4] of
> >> The Raster Tragedy at Low-Resolution, which has an interactive
> >> demonstration of the filters used in ClearType (Microsoft), CoolType
> >> (Adobe), FreeType (open source), and Quartz 2D (Apple). Hover your
> >> mouse over each of the samples in the illustration to remove the filter.
> >>
> >> Below is the relevant section of the file ftoption.h in FreeType
> >> 2.9.1 bundled with OpenJDK 12, edited for formatting:
> >>
> >> java.desktop/share/native/libfreetype/include/freetype/config/ftoption.h
> >>
> >> /*
> >> Uncomment the line below if you want to activate LCD rendering
> >> technology similar to ClearType in this build of the library. This
> >> technology triples the resolution in the direction color subpixels.
> >> To mitigate color fringes inherent to this technology, you also need
> >> to explicitly set up LCD filtering.
> >>
> >> Note that this feature is covered by several Microsoft patents
> >> and should not be activated in any default build of the library.
> >> When this macro is not defined, FreeType offers alternative LCD
> >> rendering technology that produces excellent output without LCD
> >> filtering.
> >> */
> >> /* #define FT_CONFIG_OPTION_SUBPIXEL_RENDERING */
> >>
> >> [1] http://david.freetype.org/cleartype-patents.html
> >> [2]
> >>
> https://github.com/jgneff/openjdk-freetype/blob/master/src/org/status6/FontDemo.java
> >> [3] https://github.com/adobe-fonts/source-code-pro
> >> [4] http://rastertragedy.com/RTRCh2.htm#Sec21
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181016/b17ac553/attachment-0001.html>

From jayathirth.d.v at oracle.com  Tue Oct 16 13:07:17 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Tue, 16 Oct 2018 06:07:17 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] [12] RFR JDK-8212116: IIOException "tEXt chunk
 length is not proper" on opening png file
Message-ID: <918a9d42-3b4b-43bf-a9ba-b4e8008f9bd1@default>

Hello All,

 

Please review the following fix in JDK12:

 

Bug : https://bugs.openjdk.java.net/browse/JDK-8212116

 

Webrev: http://cr.openjdk.java.net/~jdv/8212116/webrev.00/ 

 

Issue : When we try to read PNG image with no text in tEXt chunk we throw IIOException.

 

Root cause : While fixing HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8191023"JDK-8191023 we added tighter condition for chunk length in text chunks and we throw IIOException even when text length is 0. But text chunks can contain null text with just keyword and other data according to PNG spec. 

 

Solution : Allow text chunks with text length 0 in tEXt chunk. As part of this fix I have made changes to zTXt and iTXt chunk also as we will have same problem there also. In HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8191023"JDK-8191023 we added tighter checks for iCCP and sPLT chunk also, but in these chunks we should not allow them to have null compressed profile or null palette. So no changes are made in iCCP & sPLT parse functions.

 

Thanks,

Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181016/6b2b5b7c/attachment.html>

From philip.race at oracle.com  Tue Oct 16 14:15:05 2018
From: philip.race at oracle.com (Philip Race)
Date: Tue, 16 Oct 2018 07:15:05 -0700
Subject: [OpenJDK 2D-Dev] Setting the FreeType LCD filter
In-Reply-To: <CAKjRUT5t+db0u=-MD9V1C+KD+6gW_n+irEv5euXGbrud=Qggrg@mail.gmail.com>
References: <f5ef2fa9-52bf-9799-a41f-134bce17276b@status6.com>
 <CAKjRUT4CtKjG=k3m08-6_58bjM_OaFR3-3xCj0c=k_yOmuGm_A@mail.gmail.com>
 <6fd0a68f-f9bf-b3b2-1ade-21a0ff3ead94@status6.com>
 <a0c25274-0a73-da5a-d3df-1d1fec7947e2@oracle.com>
 <5BC587F0.7010807@oracle.com>
 <CAKjRUT5t+db0u=-MD9V1C+KD+6gW_n+irEv5euXGbrud=Qggrg@mail.gmail.com>
Message-ID: <5BC5F269.8020003@oracle.com>

Yes, a reliable jtreg test seems overly hard for this case. So I'll mark 
it noreg-hard.

-phil.

On 10/16/18, 12:00 AM, Laurent Bourg?s wrote:
> Phil,
> I tested John's patch sucessfully, it is complicated to write a jtreg 
> Test...
>
> OK for me as it is.
>
> Laurent
>
> Le mar. 16 oct. 2018 ? 08:40, Philip Race <philip.race at oracle.com 
> <mailto:philip.race at oracle.com>> a ?crit :
>
>     I intend to push this with myself & Laurent as reviewers.
>
>     OK by all ?
>
>     -phil.
>
>     On 10/11/18, 12:22 PM, Phil Race wrote:
>     > Very well done analysis of the options and very thorough testing of
>     > the effects
>     > on the different libraries/platforms.
>     >
>     >
>     > > There are some alternatives to setting the filter:
>     > >   ? Bundle the FreeType library by default
>     >
>     > Although the build makes this easy to set as an option, we
>     decided we
>     > prefer to
>     > use the platform library on Linux - and Solaris for that matter
>     - in
>     > our releases.
>     >
>     > So setting this option is going to be needed for some years to
>     come,
>     > until
>     > even a Linux current release like Ubuntu 18.04 is obsolete.
>     >
>     > We can't re-use the OpenJavaFX bug ID, and surprisingly I can't
>     find
>     > an open
>     > bug on this for 2D. So I've submitted
>     > https://bugs.openjdk.java.net/browse/JDK-8212071
>     >
>     > And I've attached John's images to the bug report and pasted his
>     email
>     > in there.
>     >
>     >
>     >
>     > -phil.
>     >
>     >
>     > On 10/11/2018 10:56 AM, John Neffenger wrote:
>     >> On 10/10/2018 11:15 AM, Laurent Bourg?s wrote:
>     >>> It looks awesome & promising.
>     >>
>     >> Thank you, Laurent, for looking into it so quickly!
>     >>
>     >>> PS: It is better to send plain text (long) email than sending
>     >>> external links (github).
>     >>
>     >> Thanks for the tip. Right, Web pages and repositories can be
>     deleted,
>     >> so here it is, for the record ...
>     >>
>     >> The symptoms of the problem are the same as in the link below, but
>     >> they appear in AWT and Swing applications instead of JavaFX
>     >> applications.
>     >>
>     >>   JDK-8188810: Fonts are blurry on Ubuntu 16.04 and Debian 9
>     >> https://bugs.openjdk.java.net/browse/JDK-8188810
>     >>
>     >> The description of the problem on the Java side follows.
>     >>
>     >> Synopsis: Reduce color fringes in FreeType subpixel rendering
>     >>
>     >> The text in Java applications often has severe color fringes when
>     >> using OpenJDK on Ubuntu and other Debian-based distributions
>     because
>     >> the JDK fails to set the LCD filter. Adding two lines of code
>     to the
>     >> file freetypeScaler.c fixed the problem in my tests, without any
>     >> regression errors for other Linux distributions. The patch is
>     >> attached to this message as the file freetypeScaler.diff.
>     >>
>     >> There are some alternatives to setting the filter:
>     >>
>     >>   ? Bundle the FreeType library by default and always use the new
>     >> Harmony subpixel rendering technique. This option removes the
>     >> uncertainty in the library at the expense of an additional 4.6
>     >> megabytes to the installed size ? an increase of less than one
>     >> percent. OpenJDK 12 even includes the latest FreeType 2.9.1, a
>     newer
>     >> version than the one found on most systems.
>     >>
>     >>   ? Wait another year and see what changes are made to
>     FreeType, if
>     >> any, when the ClearType patents expire. This option, though,
>     doesn?t
>     >> solve the problem that users of Ubuntu and other Debian-based
>     >> distributions have now.
>     >>
>     >> The problem originates in decisions made by the developers of
>     >> FreeType, Debian, Fedora, and OpenJDK concerning the Microsoft
>     >> ClearType patents [1].
>     >>
>     >>   ? In 2007, FreeType 2.3.0 added a compiler configuration
>     macro to
>     >> the file ftoption.h named FT_CONFIG_OPTION_SUBPIXEL_RENDERING. If
>     >> defined, the FreeType library includes patented ClearType
>     techniques
>     >> in its subpixel rendering.
>     >>
>     >>     But there?s a catch. When the ClearType methods are
>     enabled, the
>     >> subpixel rendering is not filtered, which results in severe color
>     >> fringes. Clients of the FreeType library must make an explicit
>     call
>     >> to the function FT_Library_SetLcdFilter to apply color
>     filtering. The
>     >> filter was disabled by default, explained one of its authors, ?to
>     >> avoid major surprises to existing clients, including libXft and
>     Cairo
>     >> which already perform some wacky color filtering on top of
>     FreeType.?
>     >>
>     >>   ? In 2009, Debian created a patch to FreeType 2.3.9, named
>     >> enable-subpixel-rendering.patch, that defines the macro and
>     enables
>     >> ClearType-style rendering. The change log states, ?This is
>     considered
>     >> no more or less evil than the bytecode interpreter which we also
>     >> enable.? Ubuntu, based on Debian, applies the patch as well.
>     Fedora
>     >> created the same patch in 2007, named
>     >> freetype-2.3.0-enable-spr.patch, but does not apply the patch by
>     >> default.
>     >>
>     >>   ? In 2017, FreeType 2.8.1 included a new subpixel rendering
>     >> technique, called Harmony, that is nearly identical in output
>     to the
>     >> ClearType technique but uses a different algorithm, avoiding the
>     >> patents. FreeType now uses Harmony subpixel rendering when the
>     >> ClearType methods are disabled, with no need for clients to set
>     the
>     >> LCD filter. (This would have been a good time for Debian to remove
>     >> its subpixel rendering patch.) The latest Fedora Workstation 28
>     runs
>     >> FreeType 2.8.0, which does not include Harmony.
>     >>
>     >>   ? In 2019, the Microsoft ClearType patents expire.
>     >>
>     >> So now we have two variants of the FreeType library: one that
>     >> requires a function call to set the LCD filter in Ubuntu and other
>     >> distributions based on Debian, and another that doesn?t require
>     the
>     >> function call in Red Hat Enterprise Linux, Oracle Linux, and other
>     >> distributions based on Fedora.
>     >>
>     >> To demonstrate the problem, I built four versions of the JDK
>     from the
>     >> latest OpenJDK sources. I built a version that uses the system
>     >> FreeType library and another that uses the bundled FreeType
>     library.
>     >> Then I changed the OpenJDK code to set the default LCD filter and
>     >> built the two versions again. The four builds were named:
>     >>
>     >>   jdk-12-system-lcdnone
>     >>   jdk-12-system-lcddefault
>     >>   jdk-12-bundled-lcdnone
>     >>   jdk-12-bundled-lcddefault
>     >>
>     >> The system library is FreeType 2.8.1 in Ubuntu 18.04.1 LTS,
>     which has
>     >> the Debian patch applied (ClearType methods enabled), while the
>     >> bundled library is FreeType 2.9.1 in OpenJDK 12, which uses the
>     >> library default (ClearType methods disabled). I wrote a simple
>     Java
>     >> Swing application called FontDemo [2] that displays two text areas
>     >> with the Adobe Source Code Pro font [3] in TTF and OTF formats
>     (the
>     >> latest non-variable download).
>     >>
>     >> The results are shown in the two images attached to this message:
>     >>
>     >>   fontdemo.png
>     >>     Three screenshots of the FontDemo program
>     >>
>     >>   fontdemo-detail.png
>     >>     Details from the screenshots scaled by 800 percent
>     >>
>     >> When using the Ubuntu system FreeType library, setting the LCD
>     filter
>     >> is critical. The screenshots show the ClearType-style rendering
>     >> without setting the LCD filter, and after adding the change to set
>     >> the filter. The ClearType configuration macro is defined in the
>     >> Ubuntu build of FreeType, so the function to set the filter
>     returns
>     >> success (0) when called and applies color filtering.
>     >>
>     >> When using the OpenJDK bundled FreeType library, setting the LCD
>     >> filter does nothing. The screenshots show the FreeType Harmony
>     >> rendering, which is the same whether or not the LCD filter is set.
>     >> The ClearType configuration macro is not defined in the OpenJDK
>     build
>     >> of FreeType, so the function to set the filter returns
>     >> FT_Err_Unimplemented_Feature (7) when called and does nothing.
>     >>
>     >> The test system I used is a QEMU/KVM guest virtual machine running
>     >> Ubuntu 18.04.1 LTS (Bionic Beaver) with the details shown
>     below. The
>     >> display is a 27-inch Dell UltraSharp U2717D monitor with a
>     resolution
>     >> of 2560 ? 1440 pixels at 109 pixels per inch.
>     >>
>     >> ubuntu at bionic:~$ uname -a
>     >> Linux bionic 4.15.0-36-generic #39-Ubuntu SMP
>     >>   Mon Sep 24 16:19:09 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
>     >>
>     >> ubuntu at bionic:~$ ldd --version
>     >> ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27
>     >>
>     >> ubuntu at bionic:~$ getconf GNU_LIBPTHREAD_VERSION
>     >> NPTL 2.27
>     >>
>     >> ubuntu at bionic:~$ $HOME/opt/jdk-12-system-lcdnone/bin/java -version
>     >> openjdk version "12-internal" 2019-03-19
>     >> OpenJDK Runtime Environment (build 12-internal+0-adhoc.ubuntu.jdk)
>     >> OpenJDK 64-Bit Server VM (build 12-internal+0-adhoc.ubuntu.jdk,
>     mixed
>     >> mode)
>     >>
>     >> Below are the full test results using five versions of FreeType
>     built
>     >> first with the ClearType methods disabled (the default) and then
>     >> again with them enabled. I ran all 10 libraries under OpenJDK 12,
>     >> first with no LCD filter and then again after adding the code
>     to set
>     >> the default LCD filter.
>     >>
>     >> No LCD Filter
>     >>
>     >> 2008 FreeType 2.3.5 (libfreetype.so.6.3.16) in Ubuntu 8.04 LTS
>     >>     ClearType Off: Grayscale, ClearType On: Mild fringes
>     >>
>     >> 2014 FreeType 2.5.2 (libfreetype.so.6.11.1) in Ubuntu 14.04 LTS
>     >>     ClearType Off: Grayscale, ClearType On: Severe fringes
>     >>
>     >> 2016 FreeType 2.6.1 (libfreetype.so.6.12.1) in Ubuntu 16.04 LTS
>     >>     ClearType Off: Grayscale, ClearType On: Severe fringes
>     >>
>     >> 2018 FreeType 2.8.1 (libfreetype.so.6.15.0) in Ubuntu 18.04 LTS
>     >>     ClearType Off: Harmony, ClearType On: Severe fringes
>     >>
>     >> 2019 FreeType 2.9.1 (libfreetype.so.6.16.1) in OpenJDK 12
>     >>     ClearType Off: Harmony, ClearType On: Severe fringes
>     >>
>     >> The OpenJDK does not set the FreeType LCD filter, so there are
>     severe
>     >> color fringes when using a FreeType library built with the
>     ClearType
>     >> methods enabled. The only reason the older FreeType 2.3.5 shows
>     mild
>     >> color fringes is because it uses full hinting, so the glyphs are
>     >> simply too skinny to see their colors.
>     >>
>     >> Default LCD Filter
>     >>
>     >> 2008 FreeType 2.3.5 (libfreetype.so.6.3.16) in Ubuntu 8.04 LTS
>     >>     ClearType Off: Grayscale, ClearType On: ClearType filtered
>     >>
>     >> 2014 FreeType 2.5.2 (libfreetype.so.6.11.1) in Ubuntu 14.04 LTS
>     >>     ClearType Off: Grayscale, ClearType On: ClearType filtered
>     >>
>     >> 2016 FreeType 2.6.1 (libfreetype.so.6.12.1) in Ubuntu 16.04 LTS
>     >>     ClearType Off: Grayscale, ClearType On: ClearType filtered
>     >>
>     >> 2018 FreeType 2.8.1 (libfreetype.so.6.15.0) in Ubuntu 18.04 LTS
>     >>     ClearType Off: Harmony, ClearType On: ClearType filtered
>     >>
>     >> 2019 FreeType 2.9.1 (libfreetype.so.6.16.1) in OpenJDK 12
>     >>     ClearType Off: Harmony, ClearType On: ClearType filtered
>     >>
>     >> After changing the OpenJDK to set the default LCD filter, there
>     is no
>     >> version of the FreeType library that shows the severe color
>     fringes.
>     >> Note that Fedora Workstation 28 includes FreeType 2.8.0 with the
>     >> ClearType methods disabled, so it displays grayscale anti-aliasing
>     >> for the OpenJDK whether it sets the LCD filter or not. (FreeType
>     >> 2.8.0 does not include Harmony.)
>     >>
>     >> For background information on LCD filters see Section 2.2.1 [4] of
>     >> The Raster Tragedy at Low-Resolution, which has an interactive
>     >> demonstration of the filters used in ClearType (Microsoft),
>     CoolType
>     >> (Adobe), FreeType (open source), and Quartz 2D (Apple). Hover your
>     >> mouse over each of the samples in the illustration to remove
>     the filter.
>     >>
>     >> Below is the relevant section of the file ftoption.h in FreeType
>     >> 2.9.1 bundled with OpenJDK 12, edited for formatting:
>     >>
>     >>
>     java.desktop/share/native/libfreetype/include/freetype/config/ftoption.h
>     >>
>     >> /*
>     >> Uncomment the line below if you want to activate LCD rendering
>     >> technology similar to ClearType in this build of the library. This
>     >> technology triples the resolution in the direction color subpixels.
>     >> To mitigate color fringes inherent to this technology, you also
>     need
>     >> to explicitly set up LCD filtering.
>     >>
>     >> Note that this feature is covered by several Microsoft patents
>     >> and should not be activated in any default build of the library.
>     >> When this macro is not defined, FreeType offers alternative LCD
>     >> rendering technology that produces excellent output without LCD
>     >> filtering.
>     >> */
>     >> /* #define FT_CONFIG_OPTION_SUBPIXEL_RENDERING */
>     >>
>     >> [1] http://david.freetype.org/cleartype-patents.html
>     >> [2]
>     >>
>     https://github.com/jgneff/openjdk-freetype/blob/master/src/org/status6/FontDemo.java
>     >> [3] https://github.com/adobe-fonts/source-code-pro
>     >> [4] http://rastertragedy.com/RTRCh2.htm#Sec21
>     >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181016/c2ad5fc5/attachment-0001.html>

From john at status6.com  Tue Oct 16 21:51:28 2018
From: john at status6.com (John Neffenger)
Date: Tue, 16 Oct 2018 14:51:28 -0700
Subject: [OpenJDK 2D-Dev] Setting the FreeType LCD filter
In-Reply-To: <CAKjRUT5t+db0u=-MD9V1C+KD+6gW_n+irEv5euXGbrud=Qggrg@mail.gmail.com>
References: <f5ef2fa9-52bf-9799-a41f-134bce17276b@status6.com>
 <CAKjRUT4CtKjG=k3m08-6_58bjM_OaFR3-3xCj0c=k_yOmuGm_A@mail.gmail.com>
 <6fd0a68f-f9bf-b3b2-1ade-21a0ff3ead94@status6.com>
 <a0c25274-0a73-da5a-d3df-1d1fec7947e2@oracle.com>
 <5BC587F0.7010807@oracle.com>
 <CAKjRUT5t+db0u=-MD9V1C+KD+6gW_n+irEv5euXGbrud=Qggrg@mail.gmail.com>
Message-ID: <e651597e-c6c5-cd03-c49e-1eab8bec87c8@status6.com>

On 10/16/2018 12:00 AM, Laurent Bourg?s wrote:
> I tested John's patch sucessfully, it is complicated to write a jtreg 

It would be great if someone more familiar with the code could double 
check whether that's the best place to put the call setting the filter. 
It worked with no regression in subpixel rendering for all of my tests, 
but I didn't check for any unwanted side effects unrelated to fonts.

Thanks,
John

From john at status6.com  Tue Oct 16 22:26:34 2018
From: john at status6.com (John Neffenger)
Date: Tue, 16 Oct 2018 15:26:34 -0700
Subject: [OpenJDK 2D-Dev] Setting the FreeType LCD filter
In-Reply-To: <5BC5F269.8020003@oracle.com>
References: <f5ef2fa9-52bf-9799-a41f-134bce17276b@status6.com>
 <CAKjRUT4CtKjG=k3m08-6_58bjM_OaFR3-3xCj0c=k_yOmuGm_A@mail.gmail.com>
 <6fd0a68f-f9bf-b3b2-1ade-21a0ff3ead94@status6.com>
 <a0c25274-0a73-da5a-d3df-1d1fec7947e2@oracle.com>
 <5BC587F0.7010807@oracle.com>
 <CAKjRUT5t+db0u=-MD9V1C+KD+6gW_n+irEv5euXGbrud=Qggrg@mail.gmail.com>
 <5BC5F269.8020003@oracle.com>
Message-ID: <adf1eadd-bb46-5b7b-52c1-0302de723ac3@status6.com>

On 10/16/2018 07:15 AM, Philip Race wrote:
> Yes, a reliable jtreg test seems overly hard for this case. So I'll mark 
> it noreg-hard.

One thing we could do is simply save copies of rendered text under a 
variety of configurations and compare them from one release to the next. 
Actually, FreeType is just now starting to do that itself [1].

I started to keep track on the Web page below, at least in relation to 
this particular code change, but I haven't expanded it to other font 
types or platforms yet (Windows and macOS).

OpenJDK FreeType Tests
https://github.com/jgneff/openjdk-freetype/wiki/OpenJDK-FreeType-Tests

John

[1] Develop a test framework for checking FreeType's rendering output 
<https://www.freetype.org/gsoc.html>

From philip.race at oracle.com  Tue Oct 16 22:29:43 2018
From: philip.race at oracle.com (Philip Race)
Date: Tue, 16 Oct 2018 15:29:43 -0700
Subject: [OpenJDK 2D-Dev] Setting the FreeType LCD filter
In-Reply-To: <adf1eadd-bb46-5b7b-52c1-0302de723ac3@status6.com>
References: <f5ef2fa9-52bf-9799-a41f-134bce17276b@status6.com>
 <CAKjRUT4CtKjG=k3m08-6_58bjM_OaFR3-3xCj0c=k_yOmuGm_A@mail.gmail.com>
 <6fd0a68f-f9bf-b3b2-1ade-21a0ff3ead94@status6.com>
 <a0c25274-0a73-da5a-d3df-1d1fec7947e2@oracle.com>
 <5BC587F0.7010807@oracle.com>
 <CAKjRUT5t+db0u=-MD9V1C+KD+6gW_n+irEv5euXGbrud=Qggrg@mail.gmail.com>
 <5BC5F269.8020003@oracle.com>
 <adf1eadd-bb46-5b7b-52c1-0302de723ac3@status6.com>
Message-ID: <5BC66657.2070301@oracle.com>

Well .. we have cases where we use the platform version of the 
rasteriser (as
I think you noted) and so on. We'd spend a lot of time on false positive 
failures
and updating golden images I think. Anyway I pushed the fix earlier today.

-phil.

On 10/16/18, 3:26 PM, John Neffenger wrote:
> On 10/16/2018 07:15 AM, Philip Race wrote:
>> Yes, a reliable jtreg test seems overly hard for this case. So I'll 
>> mark it noreg-hard.
>
> One thing we could do is simply save copies of rendered text under a 
> variety of configurations and compare them from one release to the 
> next. Actually, FreeType is just now starting to do that itself [1].
>
> I started to keep track on the Web page below, at least in relation to 
> this particular code change, but I haven't expanded it to other font 
> types or platforms yet (Windows and macOS).
>
> OpenJDK FreeType Tests
> https://github.com/jgneff/openjdk-freetype/wiki/OpenJDK-FreeType-Tests
>
> John
>
> [1] Develop a test framework for checking FreeType's rendering output 
> <https://www.freetype.org/gsoc.html>

From john at status6.com  Thu Oct 18 04:38:13 2018
From: john at status6.com (John Neffenger)
Date: Wed, 17 Oct 2018 21:38:13 -0700
Subject: [OpenJDK 2D-Dev] Setting the FreeType LCD filter
In-Reply-To: <5BC66657.2070301@oracle.com>
References: <f5ef2fa9-52bf-9799-a41f-134bce17276b@status6.com>
 <CAKjRUT4CtKjG=k3m08-6_58bjM_OaFR3-3xCj0c=k_yOmuGm_A@mail.gmail.com>
 <6fd0a68f-f9bf-b3b2-1ade-21a0ff3ead94@status6.com>
 <a0c25274-0a73-da5a-d3df-1d1fec7947e2@oracle.com>
 <5BC587F0.7010807@oracle.com>
 <CAKjRUT5t+db0u=-MD9V1C+KD+6gW_n+irEv5euXGbrud=Qggrg@mail.gmail.com>
 <5BC5F269.8020003@oracle.com>
 <adf1eadd-bb46-5b7b-52c1-0302de723ac3@status6.com>
 <5BC66657.2070301@oracle.com>
Message-ID: <169fd2e1-0e2e-c22b-e614-92007dd7ada5@status6.com>

On 10/16/18 2:29 PM, Philip Race wrote:
> Anyway I pushed the fix earlier today.

Thank you very much, Phil, for reading over my long problem description 
and getting a fix into the JDK so quickly.

This fix, plus the change in FreeType 2.8 that makes light hinting the 
new normal for regular LCD displays, trigger a bunch of good things in 
text rendering on Linux. [1] Fonts really don't get any better than that 
right now ? on any platform ? so thank you.

The irony is, just as Linux gets state-of-the-art native font hinting 
and subpixel anti-aliasing, Apple decides none of it is worth the 
complexity anymore and simply removes it! [2]

John

[1] https://www.freetype.org/freetype2/docs/text-rendering-general.html
[2] https://developer.apple.com/videos/play/wwdc2018/209/?time=1683

From philip.race at oracle.com  Thu Oct 18 21:39:40 2018
From: philip.race at oracle.com (Phil Race)
Date: Thu, 18 Oct 2018 14:39:40 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> java.awt.* properties initialization?
In-Reply-To: <cf4bf9f0-c4db-b2b3-f8f4-6626155311a5@oracle.com>
References: <cf4bf9f0-c4db-b2b3-f8f4-6626155311a5@oracle.com>
Message-ID: <d6dc3212-5b08-385d-47cb-f0b057c98a5a@oracle.com>

Adding 2d-dev .. as most of these are actually for 2D, not AWT, despite 
the names.

I have bugs filed to get rid of these two 2D properties :

https://bugs.openjdk.java.net/browse/JDK-8130264 : java.awt.printerjob
https://bugs.openjdk.java.net/browse/JDK-8130266 : java.awt.graphicsenv
Probably I could file another for "awt.toolkit", which is AWT.

The potential external use of these to inject replacments was made moot 
by jigsaw.

So I don't think I'd bother "moving" them, more like replacing them & 
then deleting this code.

fontpath used to be used as a workaround for failure by 2D to locate the 
system fonts
which probably is no longer needed due to better ways we have of doing 
this these days.
We probably could remove that along with the code which reads it.

I'd have to think about where we could put the isInAquaSession() logic.

-phil.


On 10/18/2018 07:22 AM, Roger Riggs wrote:
> Hi,
>
> There are a few java.awt.* properties that have support in the 
> system.c native code based on
> the operating system.?? Most do not need to be in native code and 
> decoupling the code
> would be a good cleanup.
>
> I'd like to look at the properties and move the initializations to a 
> more appropriate place.
> Since they are not used in the java.base module it would be more 
> appropriate for
> them to be handled in the java.desktop module and the appropriate 
> package.
>
> At the moment, they all can be overridden by command line arguments 
> though
> in some cases, that seems to be unintentional and perhaps undesirable.
> Most could dispatch on the os_name system property to select the 
> appropriate implementation class.
>
> I'd like to work through this issues and see if there are any special 
> considerations.
> Thanks for any comments and advice.
>
> Roger
>
>
> java.awt.graphicsenv:? java.awt.GraphicsEnvironment.java
>
> "sun.awt.CGraphicsEnvironment" "sun.awt.X11GraphicsEnvironment" 
> "sun.awt.Win32GraphicsEnvironment"
>
> awt.toolkit : java.awt.Toolkit.java
>
> "sun.awt.X11.XToolkit" "sun.lwawt.macosx.LWCToolkit" 
> "sun.awt.windows.WToolkit"
>
> java.awt.printerjob: java.awt.print.PrinterJob.java
>
> "sun.print.PSPrinterJob""sun.lwawt.macosx.CPrinterJob" 
> "sun.awt.windows.WPrinterJob"
>
> awt.headless:? This may need native code specific to the Mac.
>
> isInAquaSession() ? NULL :"true";
>
>
> sun.java2d.fontpath: sun.font.SunFontManager
> The native initialization is hooked to an environment variable 
> "JAVA2D_FONTPATH".
> Is that initialization from the environment still used or needed?
>


From Roger.Riggs at oracle.com  Thu Oct 18 21:50:18 2018
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 18 Oct 2018 17:50:18 -0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> java.awt.* properties initialization?
In-Reply-To: <d6dc3212-5b08-385d-47cb-f0b057c98a5a@oracle.com>
References: <cf4bf9f0-c4db-b2b3-f8f4-6626155311a5@oracle.com>
 <d6dc3212-5b08-385d-47cb-f0b057c98a5a@oracle.com>
Message-ID: <e2396d52-4126-7231-32f5-592cf2b524ef@oracle.com>

Hi Phil,

Thanks for filing the issues and clarifications.
I agree that removal is a great option to reduce clutter and maintenance.

I forgot to include 'sun.desktop' which seems to be only ever set to 
'gnome' on linux
and 'windows' on windows.

Thanks, Roger



On 10/18/2018 05:39 PM, Phil Race wrote:
> Adding 2d-dev .. as most of these are actually for 2D, not AWT, 
> despite the names.
>
> I have bugs filed to get rid of these two 2D properties :
>
> https://bugs.openjdk.java.net/browse/JDK-8130264 : java.awt.printerjob
> https://bugs.openjdk.java.net/browse/JDK-8130266 : java.awt.graphicsenv
> Probably I could file another for "awt.toolkit", which is AWT.
>
> The potential external use of these to inject replacments was made 
> moot by jigsaw.
>
> So I don't think I'd bother "moving" them, more like replacing them & 
> then deleting this code.
>
> fontpath used to be used as a workaround for failure by 2D to locate 
> the system fonts
> which probably is no longer needed due to better ways we have of doing 
> this these days.
> We probably could remove that along with the code which reads it.
>
> I'd have to think about where we could put the isInAquaSession() logic.
>
> -phil.
>
>
> On 10/18/2018 07:22 AM, Roger Riggs wrote:
>> Hi,
>>
>> There are a few java.awt.* properties that have support in the 
>> system.c native code based on
>> the operating system.?? Most do not need to be in native code and 
>> decoupling the code
>> would be a good cleanup.
>>
>> I'd like to look at the properties and move the initializations to a 
>> more appropriate place.
>> Since they are not used in the java.base module it would be more 
>> appropriate for
>> them to be handled in the java.desktop module and the appropriate 
>> package.
>>
>> At the moment, they all can be overridden by command line arguments 
>> though
>> in some cases, that seems to be unintentional and perhaps undesirable.
>> Most could dispatch on the os_name system property to select the 
>> appropriate implementation class.
>>
>> I'd like to work through this issues and see if there are any special 
>> considerations.
>> Thanks for any comments and advice.
>>
>> Roger
>>
>>
>> java.awt.graphicsenv:? java.awt.GraphicsEnvironment.java
>>
>> "sun.awt.CGraphicsEnvironment" "sun.awt.X11GraphicsEnvironment" 
>> "sun.awt.Win32GraphicsEnvironment"
>>
>> awt.toolkit : java.awt.Toolkit.java
>>
>> "sun.awt.X11.XToolkit" "sun.lwawt.macosx.LWCToolkit" 
>> "sun.awt.windows.WToolkit"
>>
>> java.awt.printerjob: java.awt.print.PrinterJob.java
>>
>> "sun.print.PSPrinterJob""sun.lwawt.macosx.CPrinterJob" 
>> "sun.awt.windows.WPrinterJob"
>>
>> awt.headless:? This may need native code specific to the Mac.
>>
>> isInAquaSession() ? NULL :"true";
>>
>>
>> sun.java2d.fontpath: sun.font.SunFontManager
>> The native initialization is hooked to an environment variable 
>> "JAVA2D_FONTPATH".
>> Is that initialization from the environment still used or needed?
>>
>

-- 
Thanks, Roger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181018/5db20b39/attachment.html>

From philip.race at oracle.com  Fri Oct 19 19:32:29 2018
From: philip.race at oracle.com (Phil Race)
Date: Fri, 19 Oct 2018 12:32:29 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> java.awt.* properties initialization?
In-Reply-To: <e2396d52-4126-7231-32f5-592cf2b524ef@oracle.com>
References: <cf4bf9f0-c4db-b2b3-f8f4-6626155311a5@oracle.com>
 <d6dc3212-5b08-385d-47cb-f0b057c98a5a@oracle.com>
 <e2396d52-4126-7231-32f5-592cf2b524ef@oracle.com>
Message-ID: <4a688551-184c-c050-ea0a-986d272254ac@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8212700

On 10/18/2018 02:50 PM, Roger Riggs wrote:
> Hi Phil,
>
> Thanks for filing the issues and clarifications.
> I agree that removal is a great option to reduce clutter and maintenance.
>
> I forgot to include 'sun.desktop' which seems to be only ever set to 
> 'gnome' on linux
> and 'windows' on windows.
>

Near as I can tell that may mainly have been used to select between a 
gnome & CDE/Motif desktop
Setting it to windows on windows didn't tell you anything new.
I've filed https://bugs.openjdk.java.net/browse/JDK-8212701

Also I've filed one for the AWT toolkit :
https://bugs.openjdk.java.net/browse/JDK-8212700
and another for fontpath : https://bugs.openjdk.java.net/browse/JDK-8212703

-phil.

> Thanks, Roger
>
>
>
> On 10/18/2018 05:39 PM, Phil Race wrote:
>> Adding 2d-dev .. as most of these are actually for 2D, not AWT, 
>> despite the names.
>>
>> I have bugs filed to get rid of these two 2D properties :
>>
>> https://bugs.openjdk.java.net/browse/JDK-8130264 : java.awt.printerjob
>> https://bugs.openjdk.java.net/browse/JDK-8130266 : java.awt.graphicsenv
>> Probably I could file another for "awt.toolkit", which is AWT.
>>
>> The potential external use of these to inject replacments was made 
>> moot by jigsaw.
>>
>> So I don't think I'd bother "moving" them, more like replacing them & 
>> then deleting this code.
>>
>> fontpath used to be used as a workaround for failure by 2D to locate 
>> the system fonts
>> which probably is no longer needed due to better ways we have of 
>> doing this these days.
>> We probably could remove that along with the code which reads it.
>>
>> I'd have to think about where we could put the isInAquaSession() logic.
>>
>> -phil.
>>
>>
>> On 10/18/2018 07:22 AM, Roger Riggs wrote:
>>> Hi,
>>>
>>> There are a few java.awt.* properties that have support in the 
>>> system.c native code based on
>>> the operating system.?? Most do not need to be in native code and 
>>> decoupling the code
>>> would be a good cleanup.
>>>
>>> I'd like to look at the properties and move the initializations to a 
>>> more appropriate place.
>>> Since they are not used in the java.base module it would be more 
>>> appropriate for
>>> them to be handled in the java.desktop module and the appropriate 
>>> package.
>>>
>>> At the moment, they all can be overridden by command line arguments 
>>> though
>>> in some cases, that seems to be unintentional and perhaps undesirable.
>>> Most could dispatch on the os_name system property to select the 
>>> appropriate implementation class.
>>>
>>> I'd like to work through this issues and see if there are any 
>>> special considerations.
>>> Thanks for any comments and advice.
>>>
>>> Roger
>>>
>>>
>>> java.awt.graphicsenv:? java.awt.GraphicsEnvironment.java
>>>
>>> "sun.awt.CGraphicsEnvironment" "sun.awt.X11GraphicsEnvironment" 
>>> "sun.awt.Win32GraphicsEnvironment"
>>>
>>> awt.toolkit : java.awt.Toolkit.java
>>>
>>> "sun.awt.X11.XToolkit" "sun.lwawt.macosx.LWCToolkit" 
>>> "sun.awt.windows.WToolkit"
>>>
>>> java.awt.printerjob: java.awt.print.PrinterJob.java
>>>
>>> "sun.print.PSPrinterJob""sun.lwawt.macosx.CPrinterJob" 
>>> "sun.awt.windows.WPrinterJob"
>>>
>>> awt.headless:? This may need native code specific to the Mac.
>>>
>>> isInAquaSession() ? NULL :"true";
>>>
>>>
>>> sun.java2d.fontpath: sun.font.SunFontManager
>>> The native initialization is hooked to an environment variable 
>>> "JAVA2D_FONTPATH".
>>> Is that initialization from the environment still used or needed?
>>>
>>
>
> -- 
> Thanks, Roger


From Sergey.Bylokhov at oracle.com  Mon Oct 22 23:20:31 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 22 Oct 2018 16:20:31 -0700
Subject: [OpenJDK 2D-Dev] [12] Review Request: 8212790 Javadoc cleanup of
 java.awt.color package
Message-ID: <a184bf93-fa6e-ce25-9aee-8e7cee0c60a9@oracle.com>

Hello.
Please review a javadoc "weekend cleanup" in jdk 12.

Bug: https://bugs.openjdk.java.net/browse/JDK-8212790
Webrev: http://cr.openjdk.java.net/~serb/8212790/webrev.00
Specdiff: http://cr.openjdk.java.net/~serb/8212790/specdiff.00/overview-summary.html

To check the difference I suggest to use specdiff.

Some important changes:
  - The copyright header in CMMException.java is changed. I have checked the history and confirmed that this file had the same copyright as other files in jdk6. And I guess the header was not updated when it was moved to the open repo in JDK-6662775.
  - Descriptions of ICC_ProfileGray and ICC_ProfileRGB classes are unified. These are similar classes, but the javadoc was a little bit different. Any suggestions to improve it further are welcome.

Other changes:
  - description of the class/method/field should be followed by dot
  - @param, @return should not end with a dot, except a case when more than one sentences are used
  - empty line after description/before the first tag was added
  - unnecessary empty lines were removed
  - sets of spaces in the middle of text were deleted
  - @param, @throws, @return should be aligned, to be more readable
  - unnecessary imports were removed
  - the "true"/"false" were wrapped in {@code } when necessary
  - @exception is replaced by @throws

-- 
Best regards, Sergey.

From bourges.laurent at gmail.com  Tue Oct 23 06:30:12 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Tue, 23 Oct 2018 08:30:12 +0200
Subject: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11
In-Reply-To: <5BC0B18A.90300@oracle.com>
References: <CAK9Gx1fx=w29r1BSCYwBsxqe6SMKTMpQPj30xb0-5F+0nsudMg@mail.gmail.com>
 <CAKjRUT6UqCp0aLefOy_fD86nJP40qNNJ7RqoRvZ-khsPpvvKZg@mail.gmail.com>
 <CAK9Gx1dHXTm_ctFjh0F+Mh3bMbkJ2wXhABXS7GJhCghwe_06Zw@mail.gmail.com>
 <CAKjRUT6fe+SLCO0aHXQm76CrLZJfxfK6vG6d5ZXZaB4ocEm-GA@mail.gmail.com>
 <CAK9Gx1fUrrsPTug5n0fNGEkJ=_J8L2JAqubZtNNuNL9ZaS3KxQ@mail.gmail.com>
 <CAK9Gx1czsrxtuVUo_sCbY6LR3W2wTLbgOo6TOPWZY0vEyKhtUQ@mail.gmail.com>
 <5BBE1D8D.6040806@oracle.com>
 <CAK9Gx1c81CEgz4_EnsLeP0WXu82rfsWed-iYWqhtn12fJy+wrA@mail.gmail.com>
 <CAKjRUT61HwGRuUnU6D8WA8C1nMQr9tBVuKyLtAgyHtNKJJU=hw@mail.gmail.com>
 <CAK9Gx1dvB=rBoN99zUewSBGNjpthoBQi+AyzmQbFnv-cE7wY2Q@mail.gmail.com>
 <a7abd67d-b72c-ceb1-7d7e-78df32600394@oracle.com>
 <CAKjRUT7Odx3xaYykCRPbWLTHqc6AEV59wHjeQGCp4_41FYNvSQ@mail.gmail.com>
 <CAKjRUT6VUUPg+OqCgQbJWCBoaqyYYU72CY7iQadWh0zWpj0=Dg@mail.gmail.com>
 <5BC0B18A.90300@oracle.com>
Message-ID: <CAKjRUT61cgGX9v9HqZ=nhN5tZ_iADZMO5dGTHLduANFJ_VQBOw@mail.gmail.com>

Phil,
Yesterday I started hacking ShapeSpanIterator.c to add stats: the last
stage (sort by x0) is the bottleneck.
In this case every sort takes up to 15ms per pixel row !

I will see if I can adapt Marlin's MergeSort.java to C to have an efficient
sort in-place.
Do you know if libawt has already an efficient sort instead of porting mine
?

PS: "To save the planet, make software more efficient" is my quote of the
day !

Cheers,
Laurent

Le ven. 12 oct. 2018 ? 16:37, Philip Race <philip.race at oracle.com> a ?crit :

> If there are no comments in the source, then there is no documentation :-(
> Reverse engineering/studying the code is what we'd have to do if that were
> the approach to be taken here.
>
> -phil.
>
> On 10/12/18, 2:18 AM, Laurent Bourg?s wrote:
>
> Phil,
> I looked at the hostpot in
> src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c (75%
> cpu time) and its sort algorithm looks like an insertion sort ...
> If you could give me some explanations (or documentation), I could try
> optimizing this method.
>
> Do you know if it uses an Active Edge Table (AET) or it traverses all
> segments every time ?
> i.e. segmentTable contains only ACTIVE segments or all ?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181023/18743b72/attachment.html>

From jayathirth.d.v at oracle.com  Tue Oct 23 13:38:41 2018
From: jayathirth.d.v at oracle.com (Jayathirth Rao)
Date: Tue, 23 Oct 2018 19:08:41 +0530
Subject: [OpenJDK 2D-Dev] [12] RFR JDK-8211422: Reading PNG with corrupt CRC
 for IEND chunk throws IIOException
Message-ID: <F91AE446-ED6D-4DA6-8ED4-1705BB35962F@oracle.com>

Hello All,
 
Please review the following fix in JDK12:
 
Bug : https://bugs.openjdk.java.net/browse/JDK-8211422 <https://bugs.openjdk.java.net/browse/JDK-8211422> 
 
Webrev: http://cr.openjdk.java.net/~jdv/8211422/webrev.00/ <http://cr.openjdk.java.net/~jdv/8211422/webrev.00/> 
 
Issue : When we try to read PNG image with corrupt/no 4 byte CRC data for IEND chunk we throw IIOException. We see this issue only after JDK-8164971 <https://bugs.openjdk.java.net/browse/JDK-8164971>.
 
Root cause : In JDK-8164971 <https://bugs.openjdk.java.net/browse/JDK-8164971> fix we made changes to continue reading metadata until we reach IEND chunk. Before JDK-8164971 <https://bugs.openjdk.java.net/browse/JDK-8164971> change we used to stop reading metadata as soon as we hit first IDAT chunk. According to PNG spec there can be more than one IDAT chunk/ more headers after IDAT chunk. So we need to read metadata until we hit IEND chunk. But in case of this bug we have IEND chunk but it has corrupt/no CRC chunk, so we throw IIOException(According to PNG spec every PNG chunk should contain 4 byte CRC). But lot of other decoders accept these kind of images which has no CRC chunk for IEND chunk. 
 
 
Solution : There is no need to verify CRC for IEND chunk(Chunk data length for IEND is 0). Stop reading metadata once we hit Chunk type info for IEND chunk.
 
Thanks,
Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181023/dc81f535/attachment.html>

From bourges.laurent at gmail.com  Tue Oct 23 20:37:10 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Tue, 23 Oct 2018 22:37:10 +0200
Subject: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11
In-Reply-To: <CAKjRUT61cgGX9v9HqZ=nhN5tZ_iADZMO5dGTHLduANFJ_VQBOw@mail.gmail.com>
References: <CAK9Gx1fx=w29r1BSCYwBsxqe6SMKTMpQPj30xb0-5F+0nsudMg@mail.gmail.com>
 <CAKjRUT6UqCp0aLefOy_fD86nJP40qNNJ7RqoRvZ-khsPpvvKZg@mail.gmail.com>
 <CAK9Gx1dHXTm_ctFjh0F+Mh3bMbkJ2wXhABXS7GJhCghwe_06Zw@mail.gmail.com>
 <CAKjRUT6fe+SLCO0aHXQm76CrLZJfxfK6vG6d5ZXZaB4ocEm-GA@mail.gmail.com>
 <CAK9Gx1fUrrsPTug5n0fNGEkJ=_J8L2JAqubZtNNuNL9ZaS3KxQ@mail.gmail.com>
 <CAK9Gx1czsrxtuVUo_sCbY6LR3W2wTLbgOo6TOPWZY0vEyKhtUQ@mail.gmail.com>
 <5BBE1D8D.6040806@oracle.com>
 <CAK9Gx1c81CEgz4_EnsLeP0WXu82rfsWed-iYWqhtn12fJy+wrA@mail.gmail.com>
 <CAKjRUT61HwGRuUnU6D8WA8C1nMQr9tBVuKyLtAgyHtNKJJU=hw@mail.gmail.com>
 <CAK9Gx1dvB=rBoN99zUewSBGNjpthoBQi+AyzmQbFnv-cE7wY2Q@mail.gmail.com>
 <a7abd67d-b72c-ceb1-7d7e-78df32600394@oracle.com>
 <CAKjRUT7Odx3xaYykCRPbWLTHqc6AEV59wHjeQGCp4_41FYNvSQ@mail.gmail.com>
 <CAKjRUT6VUUPg+OqCgQbJWCBoaqyYYU72CY7iQadWh0zWpj0=Dg@mail.gmail.com>
 <5BC0B18A.90300@oracle.com>
 <CAKjRUT61cgGX9v9HqZ=nhN5tZ_iADZMO5dGTHLduANFJ_VQBOw@mail.gmail.com>
Message-ID: <CAKjRUT5Raxjb5HwCqQOUUEmwvF-48Urk7Rv95eC2dAT3WM4OHQ@mail.gmail.com>

Phil,
I quickly modified the final update & sort loop to:
- move sort in another block
- use qsort() using a new comparator sortSegmentsByCurX

This improves performance in PolyLineTest by 3 times: ~1s vs 3.5s !
Apparently qsort() is not optimal (comparator can not be inlined by c) so
it may explain why Marlin (0x0 sampling) is still 2 times faster with its
custom merge-sort (in-place).

Any idea to improve C sort ?
Is it good enough ?

- USE_QSORT_X: 1
oct. 23, 2018 10:15:29 PM polylinetest.Canvas paintComponent
INFOS: Paint Time: 1,081s
INFOS: Paint Time: 1,058s
INFOS: Paint Time: 1,067s

- USE_QSORT_X: 0
oct. 23, 2018 10:18:50 PM polylinetest.Canvas paintComponent
INFOS: Paint Time: 3,318s
INFOS: Paint Time: 3,258s
INFOS: Paint Time: 3,273s

Patch:
diff -r 297450fcab26
src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c
---
a/src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c
Tue Oct 16 23:21:05 2018 +0530
+++
b/src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c
Tue Oct 23 22:31:00 2018 +0200
@@ -1243,6 +1243,18 @@
     }
 }

+/* LBO: enable (1) / disable (0) qsort on curx */
+#define USE_QSORT_X (0)
+
+static int CDECL
+sortSegmentsByCurX(const void *elem1, const void *elem2)
+{
+    jint x1 = (*(segmentData **)elem1)->curx;
+    jint x2 = (*(segmentData **)elem2)->curx;
+
+    return (x1 - x2);
+}
+
 static jboolean
 ShapeSINextSpan(void *state, jint spanbox[])
 {
@@ -1378,16 +1390,28 @@
             seg->curx = x0;
             seg->cury = y0;
             seg->error = err;
+        }

-            /* Then make sure the segment is sorted by x0 */
-            for (new = cur; new > lo; new--) {
-                segmentData *seg2 = segmentTable[new - 1];
-                if (seg2->curx <= x0) {
-                    break;
+        if (USE_QSORT_X && (hi - lo) > 100)
+        {
+            /* use quick sort on [lo - hi] range */
+            qsort(&(segmentTable[lo]), (hi - lo), sizeof(segmentData *),
+                    sortSegmentsByCurX);
+        } else {
+            for (cur = lo; cur < hi; cur++) {
+                seg = segmentTable[cur];
+                x0 = seg->curx;
+
+                /* Then make sure the segment is sorted by x0 */
+                for (new = cur; new > lo; new--) {
+                    segmentData *seg2 = segmentTable[new - 1];
+                    if (seg2->curx <= x0) {
+                        break;
+                    }
+                    segmentTable[new] = seg2;
                 }
-                segmentTable[new] = seg2;
+                segmentTable[new] = seg;
             }
-            segmentTable[new] = seg;
         }
         cur = lo;
     }

Cheers,
Laurent

Le mar. 23 oct. 2018 ? 08:30, Laurent Bourg?s <bourges.laurent at gmail.com> a
?crit :

> Phil,
> Yesterday I started hacking ShapeSpanIterator.c to add stats: the last
> stage (sort by x0) is the bottleneck.
> In this case every sort takes up to 15ms per pixel row !
>
> I will see if I can adapt Marlin's MergeSort.java to C to have an
> efficient sort in-place.
> Do you know if libawt has already an efficient sort instead of porting
> mine ?
>
> PS: "To save the planet, make software more efficient" is my quote of the
> day !
>
> Cheers,
> Laurent
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181023/6fbfcf99/attachment.html>

From krishna.addepalli at oracle.com  Wed Oct 24 09:57:10 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Wed, 24 Oct 2018 15:27:10 +0530
Subject: [OpenJDK 2D-Dev] [12] Review Request: 8212790 Javadoc cleanup
 of java.awt.color package
In-Reply-To: <a184bf93-fa6e-ce25-9aee-8e7cee0c60a9@oracle.com>
References: <a184bf93-fa6e-ce25-9aee-8e7cee0c60a9@oracle.com>
Message-ID: <9764CA92-808B-4D6B-ACE3-C78FAC07D3C9@oracle.com>

Hi Sergey,

I found a few places where @code tag should be added in ICC_Profile.java: 1570, 1601, 1894, 1895, 1902, 1904.

Thanks,
Krishna

> On 23-Oct-2018, at 4:50 AM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hello.
> Please review a javadoc "weekend cleanup" in jdk 12.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8212790
> Webrev: http://cr.openjdk.java.net/~serb/8212790/webrev.00
> Specdiff: http://cr.openjdk.java.net/~serb/8212790/specdiff.00/overview-summary.html
> 
> To check the difference I suggest to use specdiff.
> 
> Some important changes:
> - The copyright header in CMMException.java is changed. I have checked the history and confirmed that this file had the same copyright as other files in jdk6. And I guess the header was not updated when it was moved to the open repo in JDK-6662775.
> - Descriptions of ICC_ProfileGray and ICC_ProfileRGB classes are unified. These are similar classes, but the javadoc was a little bit different. Any suggestions to improve it further are welcome.
> 
> Other changes:
> - description of the class/method/field should be followed by dot
> - @param, @return should not end with a dot, except a case when more than one sentences are used
> - empty line after description/before the first tag was added
> - unnecessary empty lines were removed
> - sets of spaces in the middle of text were deleted
> - @param, @throws, @return should be aligned, to be more readable
> - unnecessary imports were removed
> - the "true"/"false" were wrapped in {@code } when necessary
> - @exception is replaced by @throws
> 
> -- 
> Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Wed Oct 24 21:50:03 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 24 Oct 2018 14:50:03 -0700
Subject: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11
In-Reply-To: <CAKjRUT5Raxjb5HwCqQOUUEmwvF-48Urk7Rv95eC2dAT3WM4OHQ@mail.gmail.com>
References: <CAK9Gx1fx=w29r1BSCYwBsxqe6SMKTMpQPj30xb0-5F+0nsudMg@mail.gmail.com>
 <CAK9Gx1dHXTm_ctFjh0F+Mh3bMbkJ2wXhABXS7GJhCghwe_06Zw@mail.gmail.com>
 <CAKjRUT6fe+SLCO0aHXQm76CrLZJfxfK6vG6d5ZXZaB4ocEm-GA@mail.gmail.com>
 <CAK9Gx1fUrrsPTug5n0fNGEkJ=_J8L2JAqubZtNNuNL9ZaS3KxQ@mail.gmail.com>
 <CAK9Gx1czsrxtuVUo_sCbY6LR3W2wTLbgOo6TOPWZY0vEyKhtUQ@mail.gmail.com>
 <5BBE1D8D.6040806@oracle.com>
 <CAK9Gx1c81CEgz4_EnsLeP0WXu82rfsWed-iYWqhtn12fJy+wrA@mail.gmail.com>
 <CAKjRUT61HwGRuUnU6D8WA8C1nMQr9tBVuKyLtAgyHtNKJJU=hw@mail.gmail.com>
 <CAK9Gx1dvB=rBoN99zUewSBGNjpthoBQi+AyzmQbFnv-cE7wY2Q@mail.gmail.com>
 <a7abd67d-b72c-ceb1-7d7e-78df32600394@oracle.com>
 <CAKjRUT7Odx3xaYykCRPbWLTHqc6AEV59wHjeQGCp4_41FYNvSQ@mail.gmail.com>
 <CAKjRUT6VUUPg+OqCgQbJWCBoaqyYYU72CY7iQadWh0zWpj0=Dg@mail.gmail.com>
 <5BC0B18A.90300@oracle.com>
 <CAKjRUT61cgGX9v9HqZ=nhN5tZ_iADZMO5dGTHLduANFJ_VQBOw@mail.gmail.com>
 <CAKjRUT5Raxjb5HwCqQOUUEmwvF-48Urk7Rv95eC2dAT3WM4OHQ@mail.gmail.com>
Message-ID: <e64cb30c-a10c-5269-6f99-0874e6d6fbe9@oracle.com>

I have no comments about the current proposal(results is good), but is that really necessary to have this implementation in native code?

On 23/10/2018 13:37, Laurent Bourg?s wrote:
> Phil,
> I quickly modified the final update & sort loop to:
> - move sort in another block
> - use qsort() using a new comparator sortSegmentsByCurX
> 
> This improves performance in PolyLineTest by 3 times: ~1s vs 3.5s !
> Apparently qsort() is not optimal (comparator can not be inlined by c) so it may explain why Marlin (0x0 sampling) is still 2 times faster with its custom merge-sort (in-place).
> 
> Any idea to improve C sort ?
> Is it good enough ?
> 
> - USE_QSORT_X: 1
> oct. 23, 2018 10:15:29 PM polylinetest.Canvas paintComponent
> INFOS: Paint Time: 1,081s
> INFOS: Paint Time: 1,058s
> INFOS: Paint Time: 1,067s
> 
> - USE_QSORT_X: 0
> oct. 23, 2018 10:18:50 PM polylinetest.Canvas paintComponent
> INFOS: Paint Time: 3,318s
> INFOS: Paint Time: 3,258s
> INFOS: Paint Time: 3,273s
> 
> Patch:
> diff -r 297450fcab26 src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c
> --- a/src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c??? Tue Oct 16 23:21:05 2018 +0530
> +++ b/src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c??? Tue Oct 23 22:31:00 2018 +0200
> @@ -1243,6 +1243,18 @@
>  ???? }
>  ?}
> 
> +/* LBO: enable (1) / disable (0) qsort on curx */
> +#define USE_QSORT_X (0)
> +
> +static int CDECL
> +sortSegmentsByCurX(const void *elem1, const void *elem2)
> +{
> +??? jint x1 = (*(segmentData **)elem1)->curx;
> +??? jint x2 = (*(segmentData **)elem2)->curx;
> +
> +??? return (x1 - x2);
> +}
> +
>  ?static jboolean
>  ?ShapeSINextSpan(void *state, jint spanbox[])
>  ?{
> @@ -1378,16 +1390,28 @@
>  ???????????? seg->curx = x0;
>  ???????????? seg->cury = y0;
>  ???????????? seg->error = err;
> +??????? }
> 
> -??????????? /* Then make sure the segment is sorted by x0 */
> -??????????? for (new = cur; new > lo; new--) {
> -??????????????? segmentData *seg2 = segmentTable[new - 1];
> -??????????????? if (seg2->curx <= x0) {
> -??????????????????? break;
> +??????? if (USE_QSORT_X && (hi - lo) > 100)
> +??????? {
> +??????????? /* use quick sort on [lo - hi] range */
> +??????????? qsort(&(segmentTable[lo]), (hi - lo), sizeof(segmentData *),
> +??????????????????? sortSegmentsByCurX);
> +??????? } else {
> +??????????? for (cur = lo; cur < hi; cur++) {
> +??????????????? seg = segmentTable[cur];
> +??????????????? x0 = seg->curx;
> +
> +??????????????? /* Then make sure the segment is sorted by x0 */
> +??????????????? for (new = cur; new > lo; new--) {
> +??????????????????? segmentData *seg2 = segmentTable[new - 1];
> +??????????????????? if (seg2->curx <= x0) {
> +??????????????????????? break;
> +??????????????????? }
> +??????????????????? segmentTable[new] = seg2;
>  ???????????????? }
> -??????????????? segmentTable[new] = seg2;
> +??????????????? segmentTable[new] = seg;
>  ???????????? }
> -??????????? segmentTable[new] = seg;
>  ???????? }
>  ???????? cur = lo;
>  ???? }
> 
> Cheers,
> Laurent
> 
> Le?mar. 23 oct. 2018 ??08:30, Laurent Bourg?s <bourges.laurent at gmail.com <mailto:bourges.laurent at gmail.com>> a ?crit?:
> 
>     Phil,
>     Yesterday I started hacking ShapeSpanIterator.c to add stats: the last stage (sort by x0) is the bottleneck.
>     In this case every sort takes up to 15ms per pixel row !
> 
>     I will see if I can adapt Marlin's MergeSort.java to C to have an efficient sort in-place.
>     Do you know if libawt has already an efficient sort instead of porting mine ?
> 
>     PS: "To save the planet, make software more efficient" is my quote of the day !
> 
>     Cheers,
>     Laurent
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Thu Oct 25 04:36:08 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 24 Oct 2018 21:36:08 -0700
Subject: [OpenJDK 2D-Dev] [12] Review Request: 8212790 Javadoc cleanup
 of java.awt.color package
In-Reply-To: <9764CA92-808B-4D6B-ACE3-C78FAC07D3C9@oracle.com>
References: <a184bf93-fa6e-ce25-9aee-8e7cee0c60a9@oracle.com>
 <9764CA92-808B-4D6B-ACE3-C78FAC07D3C9@oracle.com>
Message-ID: <8ccf2fc9-6050-f040-1c07-ddc61c12ab9a@oracle.com>

Hi, Krishna.
Thank you for review!

> 1894, 1895, 1902, 1904.
The text on the lines above is a block comment not a javadoc, the tags are not necessary there.

> 1570, 1601, 

I have fixed these:
http://cr.openjdk.java.net/~serb/8212790/webrev.01

-- 
Best regards, Sergey.

From fairoz.matte at oracle.com  Thu Oct 25 06:22:53 2018
From: fairoz.matte at oracle.com (Fairoz Matte)
Date: Wed, 24 Oct 2018 23:22:53 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] [8u] RFR: 8212914: Test
 javax/imageio/plugins/bmp/BMP8BPPLoadTest.java fails
Message-ID: <cf9eb16a-993c-4767-a993-eafe9313f0d1@default>

Hi,

Kindly review the small fix.

Background:
"javax/imageio/plugins/bmp/BMP8BPPLoadTest.java test case" has been added part of JDK-8182461, 
Test case has a dependency on input file "BMP8BPPLoadTest.PNG", during push this was missed.

In this fix test case also modified to refer the input file from same directory

JBS bug - https://bugs.openjdk.java.net/browse/JDK-8212914
Webrev - http://cr.openjdk.java.net/~fmatte/8212914/webrev.00/

Thanks,
Fairoz



From krishna.addepalli at oracle.com  Thu Oct 25 14:54:05 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Thu, 25 Oct 2018 20:24:05 +0530
Subject: [OpenJDK 2D-Dev] [12] Review Request: 8212790 Javadoc cleanup
 of java.awt.color package
In-Reply-To: <8ccf2fc9-6050-f040-1c07-ddc61c12ab9a@oracle.com>
References: <a184bf93-fa6e-ce25-9aee-8e7cee0c60a9@oracle.com>
 <9764CA92-808B-4D6B-ACE3-C78FAC07D3C9@oracle.com>
 <8ccf2fc9-6050-f040-1c07-ddc61c12ab9a@oracle.com>
Message-ID: <93979E3E-D6F7-4FB5-8DEE-165AD28EFE36@oracle.com>

+1

Krishna

> On 25-Oct-2018, at 10:06 AM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hi, Krishna.
> Thank you for review!
> 
>> 1894, 1895, 1902, 1904.
> The text on the lines above is a block comment not a javadoc, the tags are not necessary there.
> 
>> 1570, 1601, 
> 
> I have fixed these:
> http://cr.openjdk.java.net/~serb/8212790/webrev.01
> 
> -- 
> Best regards, Sergey.


From prasanta.sadhukhan at oracle.com  Fri Oct 26 03:25:32 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 26 Oct 2018 08:55:32 +0530
Subject: [OpenJDK 2D-Dev] [8u] RFR: 8212914: Test
 javax/imageio/plugins/bmp/BMP8BPPLoadTest.java fails
In-Reply-To: <cf9eb16a-993c-4767-a993-eafe9313f0d1@default>
References: <cf9eb16a-993c-4767-a993-eafe9313f0d1@default>
Message-ID: <e843aa6f-73f5-a06d-70c0-94190282ce8d@oracle.com>

Hi Fairoz,

Do you know if the bmp image file has Oracle copyright? If not, you 
cannot check it in.
Alternatively, you may get a hexdump of the bmp file and create a byte[] 
array with that hex data and create ByteArrayInputStream with that and 
use that for ImageIO as an ImageInputStream.

Regards
Prasanta
On 25-Oct-18 11:52 AM, Fairoz Matte wrote:
> Hi,
>
> Kindly review the small fix.
>
> Background:
> "javax/imageio/plugins/bmp/BMP8BPPLoadTest.java test case" has been added part of JDK-8182461,
> Test case has a dependency on input file "BMP8BPPLoadTest.PNG", during push this was missed.
>
> In this fix test case also modified to refer the input file from same directory
>
> JBS bug - https://bugs.openjdk.java.net/browse/JDK-8212914
> Webrev - http://cr.openjdk.java.net/~fmatte/8212914/webrev.00/
>
> Thanks,
> Fairoz
>
>


From bourges.laurent at gmail.com  Fri Oct 26 07:41:04 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Fri, 26 Oct 2018 09:41:04 +0200
Subject: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11
In-Reply-To: <e64cb30c-a10c-5269-6f99-0874e6d6fbe9@oracle.com>
References: <CAK9Gx1fx=w29r1BSCYwBsxqe6SMKTMpQPj30xb0-5F+0nsudMg@mail.gmail.com>
 <CAK9Gx1dHXTm_ctFjh0F+Mh3bMbkJ2wXhABXS7GJhCghwe_06Zw@mail.gmail.com>
 <CAKjRUT6fe+SLCO0aHXQm76CrLZJfxfK6vG6d5ZXZaB4ocEm-GA@mail.gmail.com>
 <CAK9Gx1fUrrsPTug5n0fNGEkJ=_J8L2JAqubZtNNuNL9ZaS3KxQ@mail.gmail.com>
 <CAK9Gx1czsrxtuVUo_sCbY6LR3W2wTLbgOo6TOPWZY0vEyKhtUQ@mail.gmail.com>
 <5BBE1D8D.6040806@oracle.com>
 <CAK9Gx1c81CEgz4_EnsLeP0WXu82rfsWed-iYWqhtn12fJy+wrA@mail.gmail.com>
 <CAKjRUT61HwGRuUnU6D8WA8C1nMQr9tBVuKyLtAgyHtNKJJU=hw@mail.gmail.com>
 <CAK9Gx1dvB=rBoN99zUewSBGNjpthoBQi+AyzmQbFnv-cE7wY2Q@mail.gmail.com>
 <a7abd67d-b72c-ceb1-7d7e-78df32600394@oracle.com>
 <CAKjRUT7Odx3xaYykCRPbWLTHqc6AEV59wHjeQGCp4_41FYNvSQ@mail.gmail.com>
 <CAKjRUT6VUUPg+OqCgQbJWCBoaqyYYU72CY7iQadWh0zWpj0=Dg@mail.gmail.com>
 <5BC0B18A.90300@oracle.com>
 <CAKjRUT61cgGX9v9HqZ=nhN5tZ_iADZMO5dGTHLduANFJ_VQBOw@mail.gmail.com>
 <CAKjRUT5Raxjb5HwCqQOUUEmwvF-48Urk7Rv95eC2dAT3WM4OHQ@mail.gmail.com>
 <e64cb30c-a10c-5269-6f99-0874e6d6fbe9@oracle.com>
Message-ID: <CAKjRUT6gaRGTtSOCxDCrgoMx4Fva3MMResVrZJge+_umEd6CHQ@mail.gmail.com>

Sergey,

Le mer. 24 oct. 2018 ? 23:50, Sergey Bylokhov <Sergey.Bylokhov at oracle.com>
a ?crit :

> I have no comments about the current proposal(results is good), but is
> that really necessary to have this implementation in native code?
>

1. I read the academic papers "Sort Race", 2016 and I will experiment their
best merge6 sort in Marlin to optimize even better the sort of crossings
(x).

It reports that linux qsort() is instezd a mergesort (sedgewick), not
optimal for ordered/reversed runs, as java Timsort does: stdlib is up to 2
times slower (worst case).

See https://arxiv.org/abs/1609.04471

2. My goal consists in fixing the worst case here, as demonstrated by this
case. I may port my MergeSort to C if interested.

Later we could get rid of this native nln-AA pipeline if we switch to
Marlin NonAA renderer like OpenJFX.

I suppose a JEP or RFE is required, isnt it ?

Cheers,
Laurent


> On 23/10/2018 13:37, Laurent Bourg?s wrote:
> > Phil,
> > I quickly modified the final update & sort loop to:
> > - move sort in another block
> > - use qsort() using a new comparator sortSegmentsByCurX
> >
> > This improves performance in PolyLineTest by 3 times: ~1s vs 3.5s !
> > Apparently qsort() is not optimal (comparator can not be inlined by c)
> so it may explain why Marlin (0x0 sampling) is still 2 times faster with
> its custom merge-sort (in-place).
> >
> > Any idea to improve C sort ?
> > Is it good enough ?
> >
> > - USE_QSORT_X: 1
> > oct. 23, 2018 10:15:29 PM polylinetest.Canvas paintComponent
> > INFOS: Paint Time: 1,081s
> > INFOS: Paint Time: 1,058s
> > INFOS: Paint Time: 1,067s
> >
> > - USE_QSORT_X: 0
> > oct. 23, 2018 10:18:50 PM polylinetest.Canvas paintComponent
> > INFOS: Paint Time: 3,318s
> > INFOS: Paint Time: 3,258s
> > INFOS: Paint Time: 3,273s
> >
> > Patch:
> > diff -r 297450fcab26
> src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c
> > ---
> a/src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c
> Tue Oct 16 23:21:05 2018 +0530
> > +++
> b/src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c
> Tue Oct 23 22:31:00 2018 +0200
> > @@ -1243,6 +1243,18 @@
> >       }
> >   }
> >
> > +/* LBO: enable (1) / disable (0) qsort on curx */
> > +#define USE_QSORT_X (0)
> > +
> > +static int CDECL
> > +sortSegmentsByCurX(const void *elem1, const void *elem2)
> > +{
> > +    jint x1 = (*(segmentData **)elem1)->curx;
> > +    jint x2 = (*(segmentData **)elem2)->curx;
> > +
> > +    return (x1 - x2);
> > +}
> > +
> >   static jboolean
> >   ShapeSINextSpan(void *state, jint spanbox[])
> >   {
> > @@ -1378,16 +1390,28 @@
> >               seg->curx = x0;
> >               seg->cury = y0;
> >               seg->error = err;
> > +        }
> >
> > -            /* Then make sure the segment is sorted by x0 */
> > -            for (new = cur; new > lo; new--) {
> > -                segmentData *seg2 = segmentTable[new - 1];
> > -                if (seg2->curx <= x0) {
> > -                    break;
> > +        if (USE_QSORT_X && (hi - lo) > 100)
> > +        {
> > +            /* use quick sort on [lo - hi] range */
> > +            qsort(&(segmentTable[lo]), (hi - lo), sizeof(segmentData *),
> > +                    sortSegmentsByCurX);
> > +        } else {
> > +            for (cur = lo; cur < hi; cur++) {
> > +                seg = segmentTable[cur];
> > +                x0 = seg->curx;
> > +
> > +                /* Then make sure the segment is sorted by x0 */
> > +                for (new = cur; new > lo; new--) {
> > +                    segmentData *seg2 = segmentTable[new - 1];
> > +                    if (seg2->curx <= x0) {
> > +                        break;
> > +                    }
> > +                    segmentTable[new] = seg2;
> >                   }
> > -                segmentTable[new] = seg2;
> > +                segmentTable[new] = seg;
> >               }
> > -            segmentTable[new] = seg;
> >           }
> >           cur = lo;
> >       }
> >
> > Cheers,
> > Laurent
> >
> > Le mar. 23 oct. 2018 ? 08:30, Laurent Bourg?s <bourges.laurent at gmail.com
> <mailto:bourges.laurent at gmail.com>> a ?crit :
> >
> >     Phil,
> >     Yesterday I started hacking ShapeSpanIterator.c to add stats: the
> last stage (sort by x0) is the bottleneck.
> >     In this case every sort takes up to 15ms per pixel row !
> >
> >     I will see if I can adapt Marlin's MergeSort.java to C to have an
> efficient sort in-place.
> >     Do you know if libawt has already an efficient sort instead of
> porting mine ?
> >
> >     PS: "To save the planet, make software more efficient" is my quote
> of the day !
> >
> >     Cheers,
> >     Laurent
> >
>
>
> --
> Best regards, Sergey.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181026/e4a97bbd/attachment.html>

From jayathirth.d.v at oracle.com  Fri Oct 26 09:05:52 2018
From: jayathirth.d.v at oracle.com (Jayathirth Rao)
Date: Fri, 26 Oct 2018 14:35:52 +0530
Subject: [OpenJDK 2D-Dev] [12] RFR JDK-8212865: Broken external link to
 TIFF6.pdf in ImageIO package-info.java
Message-ID: <A1F8555B-745D-4789-9BC8-D5FC46FEF629@oracle.com>

Hello All,

Please review the following fix in JDK 12:

Bug : https://bugs.openjdk.java.net/browse/JDK-8212865 <https://bugs.openjdk.java.net/browse/JDK-8212865>
Webrev : http://cr.openjdk.java.net/~jdv/8212865/webrev.00/ <http://cr.openjdk.java.net/~jdv/8212865/webrev.00/> 

Thanks,
Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181026/82b821d6/attachment-0001.html>

From prasanta.sadhukhan at oracle.com  Fri Oct 26 09:31:32 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 26 Oct 2018 15:01:32 +0530
Subject: [OpenJDK 2D-Dev] [12] RFR JDK-8212865: Broken external link to
 TIFF6.pdf in ImageIO package-info.java
In-Reply-To: <A1F8555B-745D-4789-9BC8-D5FC46FEF629@oracle.com>
References: <A1F8555B-745D-4789-9BC8-D5FC46FEF629@oracle.com>
Message-ID: <19485939-9920-9869-2ed4-82b4d64b4fed@oracle.com>

looks fine.

Regards
Prasanta
On 26-Oct-18 2:35 PM, Jayathirth Rao wrote:
> Hello All,
>
> Please review the following fix in JDK 12:
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8212865
> Webrev : http://cr.openjdk.java.net/~jdv/8212865/webrev.00/ 
> <http://cr.openjdk.java.net/%7Ejdv/8212865/webrev.00/>
>
> Thanks,
> Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181026/7e3f8b10/attachment.html>

From fairoz.matte at oracle.com  Fri Oct 26 16:33:26 2018
From: fairoz.matte at oracle.com (Fairoz Matte)
Date: Fri, 26 Oct 2018 09:33:26 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] [8u] RFR: 8212914: Test
 javax/imageio/plugins/bmp/BMP8BPPLoadTest.java fails
In-Reply-To: <e843aa6f-73f5-a06d-70c0-94190282ce8d@oracle.com>
References: <cf9eb16a-993c-4767-a993-eafe9313f0d1@default>
 <e843aa6f-73f5-a06d-70c0-94190282ce8d@oracle.com>
Message-ID: <01a3ef25-4475-46d6-9bd2-bf41db6e5845@default>

Hi Prasanta,

Thanks for looking into it.

> -----Original Message-----
> From: Prasanta Sadhukhan
> Sent: Friday, October 26, 2018 8:56 AM
> To: Fairoz Matte <fairoz.matte at oracle.com>; 2d-dev at openjdk.java.net
> Subject: Re: [OpenJDK 2D-Dev] [8u] RFR: 8212914: Test
> javax/imageio/plugins/bmp/BMP8BPPLoadTest.java fails
> 
> Hi Fairoz,
> 
> Do you know if the bmp image file has Oracle copyright? If not, you cannot
> check it in.

I was not aware of it. Yes image file is not Oracle copyright compliant.

> Alternatively, you may get a hexdump of the bmp file and create a byte[]
> array with that hex data and create ByteArrayInputStream with that and use
> that for ImageIO as an ImageInputStream.

Yes it is good approach, here is the updated webrev
http://cr.openjdk.java.net/~fmatte/8212914/webrev.01/

Thanks,
Fairoz
> 
> Regards
> Prasanta
> On 25-Oct-18 11:52 AM, Fairoz Matte wrote:
> > Hi,
> >
> > Kindly review the small fix.
> >
> > Background:
> > "javax/imageio/plugins/bmp/BMP8BPPLoadTest.java test case" has been
> > added part of JDK-8182461, Test case has a dependency on input file
> "BMP8BPPLoadTest.PNG", during push this was missed.
> >
> > In this fix test case also modified to refer the input file from same
> > directory
> >
> > JBS bug - https://bugs.openjdk.java.net/browse/JDK-8212914
> > Webrev - http://cr.openjdk.java.net/~fmatte/8212914/webrev.00/
> >
> > Thanks,
> > Fairoz
> >
> >
> 

From philip.race at oracle.com  Sat Oct 27 20:02:20 2018
From: philip.race at oracle.com (Philip Race)
Date: Sat, 27 Oct 2018 13:02:20 -0700
Subject: [OpenJDK 2D-Dev] [12] Review Request: 8212790 Javadoc cleanup
 of java.awt.color package
In-Reply-To: <8ccf2fc9-6050-f040-1c07-ddc61c12ab9a@oracle.com>
References: <a184bf93-fa6e-ce25-9aee-8e7cee0c60a9@oracle.com>
 <9764CA92-808B-4D6B-ACE3-C78FAC07D3C9@oracle.com>
 <8ccf2fc9-6050-f040-1c07-ddc61c12ab9a@oracle.com>
Message-ID: <5BD4C44C.4080105@oracle.com>

Looks mostly OK.

I am wondering why you took out the unordered list here :
https://docs.oracle.com/javase/9/docs/api/java/awt/color/ICC_ProfileRGB.html

The specdiff *maybe* doesn't really tell me what it looks like now but I 
don't see how
it can still be a list ...

May I assume you tested out any newly added links ?
eg

   73  * spaces via {@link ColorSpace#getInstance}.

Looks straightforward so I don't expect any issues, just checking.

Also it looks as if some lines got longer due to reformatting, are they 
are still within bounds ?

eg

- *
- * A subclass of the ICC_Profile class which represents profiles
- * which meet the following criteria: the color space type of the
- * profile is TYPE_GRAY and the profile includes the grayTRCTag and
- * mediaWhitePointTag tags.  Examples of this kind of profile are
- * monochrome input profiles, monochrome display profiles, and
- * monochrome output profiles.  The getInstance methods in the
- * ICC_Profile class will
- * return an ICC_ProfileGray object when the above conditions are
- * met.  The advantage of this class is that it provides a lookup
- * table that Java or native methods may be able to use directly to
- * optimize color conversion in some cases.
+ * The {@code ICC_ProfileGray} class is a subclass of the {@code ICC_Profile}
+ * class that represents profiles which meet the following criteria: the color
+ * space type of the profile is {@code TYPE_GRAY} and the profile includes the
+ * {@code grayTRCTag} and {@code mediaWhitePointTag} tags. The
+ * {@code getInstance} methods in the {@code ICC_Profile} class will return an
+ * {@code ICC_ProfileGray} object when the above conditions are met. Examples of
+ * this kind of profile are monochrome input profiles, monochrome display
+ * profiles, and monochrome output profiles.
+ *<p>
+ * The advantage of this class is that it provides a lookup table that Java
+ * or native methods can use directly to optimize color conversion in some
+ * cases.



-phil

On 10/24/18, 9:36 PM, Sergey Bylokhov wrote:
> Hi, Krishna.
> Thank you for review!
>
>> 1894, 1895, 1902, 1904.
> The text on the lines above is a block comment not a javadoc, the tags 
> are not necessary there.
>
>> 1570, 1601, 
>
> I have fixed these:
> http://cr.openjdk.java.net/~serb/8212790/webrev.01
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181027/1439f5aa/attachment.html>

From prasanta.sadhukhan at oracle.com  Mon Oct 29 06:47:58 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Mon, 29 Oct 2018 12:17:58 +0530
Subject: [OpenJDK 2D-Dev] [8u] RFR: 8212914: Test
 javax/imageio/plugins/bmp/BMP8BPPLoadTest.java fails
In-Reply-To: <01a3ef25-4475-46d6-9bd2-bf41db6e5845@default>
References: <cf9eb16a-993c-4767-a993-eafe9313f0d1@default>
 <e843aa6f-73f5-a06d-70c0-94190282ce8d@oracle.com>
 <01a3ef25-4475-46d6-9bd2-bf41db6e5845@default>
Message-ID: <dae481e0-52a4-6626-7d2a-6674c7cc3a43@oracle.com>

Hi Fairoz,

I do not see ImageIO.read and ImageIO.createImageInputStream throwing 
IOB exception in the spec, it throws IOException so I guess there's no 
point catching IOB.
Also, you need to add this bugid to @bug tag and also remove @author tag 
which we do not recommend now. Also, can you please indent byte[] data ?

Regards
Prasanta
On 26-Oct-18 10:03 PM, Fairoz Matte wrote:
> Hi Prasanta,
>
> Thanks for looking into it.
>
>> -----Original Message-----
>> From: Prasanta Sadhukhan
>> Sent: Friday, October 26, 2018 8:56 AM
>> To: Fairoz Matte <fairoz.matte at oracle.com>; 2d-dev at openjdk.java.net
>> Subject: Re: [OpenJDK 2D-Dev] [8u] RFR: 8212914: Test
>> javax/imageio/plugins/bmp/BMP8BPPLoadTest.java fails
>>
>> Hi Fairoz,
>>
>> Do you know if the bmp image file has Oracle copyright? If not, you cannot
>> check it in.
> I was not aware of it. Yes image file is not Oracle copyright compliant.
>
>> Alternatively, you may get a hexdump of the bmp file and create a byte[]
>> array with that hex data and create ByteArrayInputStream with that and use
>> that for ImageIO as an ImageInputStream.
> Yes it is good approach, here is the updated webrev
> http://cr.openjdk.java.net/~fmatte/8212914/webrev.01/
>
> Thanks,
> Fairoz
>> Regards
>> Prasanta
>> On 25-Oct-18 11:52 AM, Fairoz Matte wrote:
>>> Hi,
>>>
>>> Kindly review the small fix.
>>>
>>> Background:
>>> "javax/imageio/plugins/bmp/BMP8BPPLoadTest.java test case" has been
>>> added part of JDK-8182461, Test case has a dependency on input file
>> "BMP8BPPLoadTest.PNG", during push this was missed.
>>> In this fix test case also modified to refer the input file from same
>>> directory
>>>
>>> JBS bug - https://bugs.openjdk.java.net/browse/JDK-8212914
>>> Webrev - http://cr.openjdk.java.net/~fmatte/8212914/webrev.00/
>>>
>>> Thanks,
>>> Fairoz
>>>
>>>


From Sergey.Bylokhov at oracle.com  Mon Oct 29 19:53:03 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 29 Oct 2018 12:53:03 -0700
Subject: [OpenJDK 2D-Dev] [12] Review Request: 8212790 Javadoc cleanup
 of java.awt.color package
In-Reply-To: <5BD4C44C.4080105@oracle.com>
References: <a184bf93-fa6e-ce25-9aee-8e7cee0c60a9@oracle.com>
 <9764CA92-808B-4D6B-ACE3-C78FAC07D3C9@oracle.com>
 <8ccf2fc9-6050-f040-1c07-ddc61c12ab9a@oracle.com>
 <5BD4C44C.4080105@oracle.com>
Message-ID: <cb2adbd0-4add-5eb5-3341-df95b64b6f8b@oracle.com>

Hi, Phil.
See my comments inline:

On 27/10/2018 13:02, Philip Race wrote:
> I am wondering why you took out the unordered list here :
> https://docs.oracle.com/javase/9/docs/api/java/awt/color/ICC_ProfileRGB.html
> 
> The specdiff *maybe* doesn't really tell me what it looks like now but I don't see how
> it can still be a list ...

I have changed it from the list to the plain text(this text is similar as in ICC_ProfileGray), the reason is that the first sentence in the class description is used as a summary of the class in the package javadoc:
https://docs.oracle.com/javase/9/docs/api/java/awt/color/package-summary.html

And before the fix it was appeared as a plain text(w/o list). So I unified it for all places:
http://cr.openjdk.java.net/~serb/8212790/specdiff.00/java.desktop/java/awt/color/package-summary.html

> 
> May I assume you tested out any newly added links ?
> eg
> 
> 73 * spaces via {@link ColorSpace#getInstance}.

yes.

> 
> Looks straightforward so I don't expect any issues, just checking.
> 
> Also it looks as if some lines got longer due to reformatting, are they are still within bounds ?

Correct, this is one of the goal of the fix.

> 
> eg
> 
> - *
> - * A subclass of the ICC_Profile class which represents profiles
> - * which meet the following criteria: the color space type of the
> - * profile is TYPE_GRAY and the profile includes the grayTRCTag and
> - * mediaWhitePointTag tags. Examples of this kind of profile are
> - * monochrome input profiles, monochrome display profiles, and
> - * monochrome output profiles. The getInstance methods in the
> - * ICC_Profile class will
> - * return an ICC_ProfileGray object when the above conditions are
> - * met. The advantage of this class is that it provides a lookup
> - * table that Java or native methods may be able to use directly to
> - * optimize color conversion in some cases.
> + * The {@code ICC_ProfileGray} class is a subclass of the {@code ICC_Profile}
> + * class that represents profiles which meet the following criteria: the color
> + * space type of the profile is {@code TYPE_GRAY} and the profile includes the
> + * {@code grayTRCTag} and {@code mediaWhitePointTag} tags. The
> + * {@code getInstance} methods in the {@code ICC_Profile} class will return an
> + * {@code ICC_ProfileGray} object when the above conditions are met. Examples of
> + * this kind of profile are monochrome input profiles, monochrome display
> + * profiles, and monochrome output profiles.
> + * <p>
> + * The advantage of this class is that it provides a lookup table that Java
> + * or native methods can use directly to optimize color conversion in some
> + * cases.
> 
> 
> -phil
> 
> On 10/24/18, 9:36 PM, Sergey Bylokhov wrote:
>> Hi, Krishna.
>> Thank you for review!
>>
>>> 1894, 1895, 1902, 1904.
>> The text on the lines above is a block comment not a javadoc, the tags are not necessary there.
>>
>>> 1570, 1601, 
>>
>> I have fixed these:
>> http://cr.openjdk.java.net/~serb/8212790/webrev.01
>>


-- 
Best regards, Sergey.

From philip.race at oracle.com  Mon Oct 29 21:00:36 2018
From: philip.race at oracle.com (Phil Race)
Date: Mon, 29 Oct 2018 14:00:36 -0700
Subject: [OpenJDK 2D-Dev] [12] Review Request: 8212790 Javadoc cleanup
 of java.awt.color package
In-Reply-To: <cb2adbd0-4add-5eb5-3341-df95b64b6f8b@oracle.com>
References: <a184bf93-fa6e-ce25-9aee-8e7cee0c60a9@oracle.com>
 <9764CA92-808B-4D6B-ACE3-C78FAC07D3C9@oracle.com>
 <8ccf2fc9-6050-f040-1c07-ddc61c12ab9a@oracle.com>
 <5BD4C44C.4080105@oracle.com>
 <cb2adbd0-4add-5eb5-3341-df95b64b6f8b@oracle.com>
Message-ID: <e70d4083-d3f5-9632-706b-5225407f323c@oracle.com>



On 10/29/18 12:53 PM, Sergey Bylokhov wrote:
> Hi, Phil.
> See my comments inline:
>
> On 27/10/2018 13:02, Philip Race wrote:
>> I am wondering why you took out the unordered list here :
>> https://docs.oracle.com/javase/9/docs/api/java/awt/color/ICC_ProfileRGB.html 
>>
>>
>> The specdiff *maybe* doesn't really tell me what it looks like now 
>> but I don't see how
>> it can still be a list ...
>
> I have changed it from the list to the plain text(this text is similar 
> as in ICC_ProfileGray), the reason is that the first sentence in the 
> class description is used as a summary of the class in the package 
> javadoc:
> https://docs.oracle.com/javase/9/docs/api/java/awt/color/package-summary.html 
>

I see. OK. Approved.

-phil.

>
> And before the fix it was appeared as a plain text(w/o list). So I 
> unified it for all places:
> http://cr.openjdk.java.net/~serb/8212790/specdiff.00/java.desktop/java/awt/color/package-summary.html 
>
>
>>
>> May I assume you tested out any newly added links ?
>> eg
>>
>> 73 * spaces via {@link ColorSpace#getInstance}.
>
> yes.
>
>>
>> Looks straightforward so I don't expect any issues, just checking.
>>
>> Also it looks as if some lines got longer due to reformatting, are 
>> they are still within bounds ?
>
> Correct, this is one of the goal of the fix.
>
>>
>> eg
>>
>> - *
>> - * A subclass of the ICC_Profile class which represents profiles
>> - * which meet the following criteria: the color space type of the
>> - * profile is TYPE_GRAY and the profile includes the grayTRCTag and
>> - * mediaWhitePointTag tags. Examples of this kind of profile are
>> - * monochrome input profiles, monochrome display profiles, and
>> - * monochrome output profiles. The getInstance methods in the
>> - * ICC_Profile class will
>> - * return an ICC_ProfileGray object when the above conditions are
>> - * met. The advantage of this class is that it provides a lookup
>> - * table that Java or native methods may be able to use directly to
>> - * optimize color conversion in some cases.
>> + * The {@code ICC_ProfileGray} class is a subclass of the {@code 
>> ICC_Profile}
>> + * class that represents profiles which meet the following criteria: 
>> the color
>> + * space type of the profile is {@code TYPE_GRAY} and the profile 
>> includes the
>> + * {@code grayTRCTag} and {@code mediaWhitePointTag} tags. The
>> + * {@code getInstance} methods in the {@code ICC_Profile} class will 
>> return an
>> + * {@code ICC_ProfileGray} object when the above conditions are met. 
>> Examples of
>> + * this kind of profile are monochrome input profiles, monochrome 
>> display
>> + * profiles, and monochrome output profiles.
>> + * <p>
>> + * The advantage of this class is that it provides a lookup table 
>> that Java
>> + * or native methods can use directly to optimize color conversion 
>> in some
>> + * cases.
>>
>>
>> -phil
>>
>> On 10/24/18, 9:36 PM, Sergey Bylokhov wrote:
>>> Hi, Krishna.
>>> Thank you for review!
>>>
>>>> 1894, 1895, 1902, 1904.
>>> The text on the lines above is a block comment not a javadoc, the 
>>> tags are not necessary there.
>>>
>>>> 1570, 1601, 
>>>
>>> I have fixed these:
>>> http://cr.openjdk.java.net/~serb/8212790/webrev.01
>>>
>
>


From Sergey.Bylokhov at oracle.com  Tue Oct 30 00:59:14 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 29 Oct 2018 17:59:14 -0700
Subject: [OpenJDK 2D-Dev] [12] Review Request: 8211992
 GraphicsConfiguration.getDevice().getDisplayMode() causes JVM crash on Mac
In-Reply-To: <92a3b11d-6734-7aeb-0520-7ae0279d24a9@oracle.com>
References: <92a3b11d-6734-7aeb-0520-7ae0279d24a9@oracle.com>
Message-ID: <0e875c67-a051-d618-9047-29f09d4f28f8@oracle.com>

Any volunteers to review? =)

On 15/10/2018 18:11, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk 12.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8211992
> Webrev: http://cr.openjdk.java.net/~serb/8211992/webrev.00
> 
> Short description:
>  ? The root cause is how we use CoreGraphics display ID. This identifier can become non-valid at any time therefore methods, which is using this id should be ready to it. And this bug found a few places which does not take care about the rule above.
> 
> Long description:
>  ? In the CGraphicsDevice class we maintain the ID for the native screen. This ID usually changed when the user adds/removes monitors to the system. Since using invalid id can cause NULL result in the native code we tries to workaround it by two steps:
> 
>  ? Step (1) If the monitor is removed from the system, then we reassign its displayid to the primary screen. So if the user will holds the reference to this GDevice, it will use the MainDisplay. But note that if the user will remove the main screen again then the old screen, which were removed previously, will not be updated(but will use an invalid displayid).
> 
>  ? Step (2) Some of the native methods in CGraphicsDevice class are ready to NULL and provide some meaningful defaults, like 72 dpi. But some others methods are not ready for that, like nativeGetDisplayMode/etc.
> 
> Fix description:
>  ?- I have minimized/dropped the usage of displayid outside of CGraphicsDevice class, in CRobot it was unused, and the code from CGraphicsConfig.m was moved to CGraphicsDevice.m.
>  ?- In CGraphicsEnvironment class we now maintain the list of old devices, which is updated for all _displayReconfiguration events. This is the same implementation as on windows in Win32GraphicsEnvironment.java
>  ?- I have added some default values to all native methods also. Just to cover the rare case when we call the method and displayid became invalid at the same moment.
> 


-- 
Best regards, Sergey.

From fairoz.matte at oracle.com  Tue Oct 30 04:43:27 2018
From: fairoz.matte at oracle.com (Fairoz Matte)
Date: Mon, 29 Oct 2018 21:43:27 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] [8u] RFR: 8212914: Test
 javax/imageio/plugins/bmp/BMP8BPPLoadTest.java fails
In-Reply-To: <dae481e0-52a4-6626-7d2a-6674c7cc3a43@oracle.com>
References: <cf9eb16a-993c-4767-a993-eafe9313f0d1@default>
 <e843aa6f-73f5-a06d-70c0-94190282ce8d@oracle.com>
 <01a3ef25-4475-46d6-9bd2-bf41db6e5845@default>
 <dae481e0-52a4-6626-7d2a-6674c7cc3a43@oracle.com>
Message-ID: <6164ba88-a412-46dc-8c09-3ba77b60fc32@default>

Hi Prasanta,

> -----Original Message-----
> From: Prasanta Sadhukhan
> Sent: Monday, October 29, 2018 12:18 PM
> To: Fairoz Matte <fairoz.matte at oracle.com>; 2d-dev at openjdk.java.net
> Subject: Re: [OpenJDK 2D-Dev] [8u] RFR: 8212914: Test
> javax/imageio/plugins/bmp/BMP8BPPLoadTest.java fails
> 
> Hi Fairoz,
> 
> I do not see ImageIO.read and ImageIO.createImageInputStream throwing
> IOB exception in the spec, it throws IOException so I guess there's no point
> catching IOB.

This test case has been added as part of "JDK-8182461: IndexOutOfBoundsException when reading indexed color BMP"
Due to missing "break" IOB exception was generated.

> Also, you need to add this bugid to @bug tag and also remove @author tag
> which we do not recommend now. Also, can you please indent byte[] data ?

Yes updated all, here is the updated webrev.
http://cr.openjdk.java.net/~fmatte/8212914/webrev.02/

Thanks,
Fairoz
> 
> Regards
> Prasanta
> On 26-Oct-18 10:03 PM, Fairoz Matte wrote:
> > Hi Prasanta,
> >
> > Thanks for looking into it.
> >
> >> -----Original Message-----
> >> From: Prasanta Sadhukhan
> >> Sent: Friday, October 26, 2018 8:56 AM
> >> To: Fairoz Matte <fairoz.matte at oracle.com>; 2d-dev at openjdk.java.net
> >> Subject: Re: [OpenJDK 2D-Dev] [8u] RFR: 8212914: Test
> >> javax/imageio/plugins/bmp/BMP8BPPLoadTest.java fails
> >>
> >> Hi Fairoz,
> >>
> >> Do you know if the bmp image file has Oracle copyright? If not, you
> >> cannot check it in.
> > I was not aware of it. Yes image file is not Oracle copyright compliant.
> >
> >> Alternatively, you may get a hexdump of the bmp file and create a
> >> byte[] array with that hex data and create ByteArrayInputStream with
> >> that and use that for ImageIO as an ImageInputStream.
> > Yes it is good approach, here is the updated webrev
> > http://cr.openjdk.java.net/~fmatte/8212914/webrev.01/
> >
> > Thanks,
> > Fairoz
> >> Regards
> >> Prasanta
> >> On 25-Oct-18 11:52 AM, Fairoz Matte wrote:
> >>> Hi,
> >>>
> >>> Kindly review the small fix.
> >>>
> >>> Background:
> >>> "javax/imageio/plugins/bmp/BMP8BPPLoadTest.java test case" has
> been
> >>> added part of JDK-8182461, Test case has a dependency on input file
> >> "BMP8BPPLoadTest.PNG", during push this was missed.
> >>> In this fix test case also modified to refer the input file from
> >>> same directory
> >>>
> >>> JBS bug - https://bugs.openjdk.java.net/browse/JDK-8212914
> >>> Webrev - http://cr.openjdk.java.net/~fmatte/8212914/webrev.00/
> >>>
> >>> Thanks,
> >>> Fairoz
> >>>
> >>>
> 

From prasanta.sadhukhan at oracle.com  Tue Oct 30 06:54:16 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 30 Oct 2018 12:24:16 +0530
Subject: [OpenJDK 2D-Dev] [8u] RFR: 8212914: Test
 javax/imageio/plugins/bmp/BMP8BPPLoadTest.java fails
In-Reply-To: <6164ba88-a412-46dc-8c09-3ba77b60fc32@default>
References: <cf9eb16a-993c-4767-a993-eafe9313f0d1@default>
 <e843aa6f-73f5-a06d-70c0-94190282ce8d@oracle.com>
 <01a3ef25-4475-46d6-9bd2-bf41db6e5845@default>
 <dae481e0-52a4-6626-7d2a-6674c7cc3a43@oracle.com>
 <6164ba88-a412-46dc-8c09-3ba77b60fc32@default>
Message-ID: <9158867f-58a3-0449-5fac-3e5122380940@oracle.com>

Hi Fairoz,

@bug tag should not spearate bugs by commas, just by spaces. other than 
that, looks ok to me.

Regards
Prasanta
On 30-Oct-18 10:13 AM, Fairoz Matte wrote:
> Hi Prasanta,
>
>> -----Original Message-----
>> From: Prasanta Sadhukhan
>> Sent: Monday, October 29, 2018 12:18 PM
>> To: Fairoz Matte <fairoz.matte at oracle.com>; 2d-dev at openjdk.java.net
>> Subject: Re: [OpenJDK 2D-Dev] [8u] RFR: 8212914: Test
>> javax/imageio/plugins/bmp/BMP8BPPLoadTest.java fails
>>
>> Hi Fairoz,
>>
>> I do not see ImageIO.read and ImageIO.createImageInputStream throwing
>> IOB exception in the spec, it throws IOException so I guess there's no point
>> catching IOB.
> This test case has been added as part of "JDK-8182461: IndexOutOfBoundsException when reading indexed color BMP"
> Due to missing "break" IOB exception was generated.
>
>> Also, you need to add this bugid to @bug tag and also remove @author tag
>> which we do not recommend now. Also, can you please indent byte[] data ?
> Yes updated all, here is the updated webrev.
> http://cr.openjdk.java.net/~fmatte/8212914/webrev.02/
>
> Thanks,
> Fairoz
>> Regards
>> Prasanta
>> On 26-Oct-18 10:03 PM, Fairoz Matte wrote:
>>> Hi Prasanta,
>>>
>>> Thanks for looking into it.
>>>
>>>> -----Original Message-----
>>>> From: Prasanta Sadhukhan
>>>> Sent: Friday, October 26, 2018 8:56 AM
>>>> To: Fairoz Matte <fairoz.matte at oracle.com>; 2d-dev at openjdk.java.net
>>>> Subject: Re: [OpenJDK 2D-Dev] [8u] RFR: 8212914: Test
>>>> javax/imageio/plugins/bmp/BMP8BPPLoadTest.java fails
>>>>
>>>> Hi Fairoz,
>>>>
>>>> Do you know if the bmp image file has Oracle copyright? If not, you
>>>> cannot check it in.
>>> I was not aware of it. Yes image file is not Oracle copyright compliant.
>>>
>>>> Alternatively, you may get a hexdump of the bmp file and create a
>>>> byte[] array with that hex data and create ByteArrayInputStream with
>>>> that and use that for ImageIO as an ImageInputStream.
>>> Yes it is good approach, here is the updated webrev
>>> http://cr.openjdk.java.net/~fmatte/8212914/webrev.01/
>>>
>>> Thanks,
>>> Fairoz
>>>> Regards
>>>> Prasanta
>>>> On 25-Oct-18 11:52 AM, Fairoz Matte wrote:
>>>>> Hi,
>>>>>
>>>>> Kindly review the small fix.
>>>>>
>>>>> Background:
>>>>> "javax/imageio/plugins/bmp/BMP8BPPLoadTest.java test case" has
>> been
>>>>> added part of JDK-8182461, Test case has a dependency on input file
>>>> "BMP8BPPLoadTest.PNG", during push this was missed.
>>>>> In this fix test case also modified to refer the input file from
>>>>> same directory
>>>>>
>>>>> JBS bug - https://bugs.openjdk.java.net/browse/JDK-8212914
>>>>> Webrev - http://cr.openjdk.java.net/~fmatte/8212914/webrev.00/
>>>>>
>>>>> Thanks,
>>>>> Fairoz
>>>>>
>>>>>


From fairoz.matte at oracle.com  Tue Oct 30 08:03:16 2018
From: fairoz.matte at oracle.com (Fairoz Matte)
Date: Tue, 30 Oct 2018 01:03:16 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] [8u] RFR: 8212914: Test
 javax/imageio/plugins/bmp/BMP8BPPLoadTest.java fails
In-Reply-To: <9158867f-58a3-0449-5fac-3e5122380940@oracle.com>
References: <cf9eb16a-993c-4767-a993-eafe9313f0d1@default>
 <e843aa6f-73f5-a06d-70c0-94190282ce8d@oracle.com>
 <01a3ef25-4475-46d6-9bd2-bf41db6e5845@default>
 <dae481e0-52a4-6626-7d2a-6674c7cc3a43@oracle.com>
 <6164ba88-a412-46dc-8c09-3ba77b60fc32@default>
 <9158867f-58a3-0449-5fac-3e5122380940@oracle.com>
Message-ID: <4e5adc69-99af-4623-9835-837efb74cf7c@default>

Thanks Prasanta,

I will update that, need one more review on this?

Thanks,
Fairoz

> -----Original Message-----
> From: Prasanta Sadhukhan
> Sent: Tuesday, October 30, 2018 12:24 PM
> To: Fairoz Matte <fairoz.matte at oracle.com>; 2d-dev at openjdk.java.net
> Subject: Re: [OpenJDK 2D-Dev] [8u] RFR: 8212914: Test
> javax/imageio/plugins/bmp/BMP8BPPLoadTest.java fails
> 
> Hi Fairoz,
> 
> @bug tag should not spearate bugs by commas, just by spaces. other than
> that, looks ok to me.
> 
> Regards
> Prasanta
> On 30-Oct-18 10:13 AM, Fairoz Matte wrote:
> > Hi Prasanta,
> >
> >> -----Original Message-----
> >> From: Prasanta Sadhukhan
> >> Sent: Monday, October 29, 2018 12:18 PM
> >> To: Fairoz Matte <fairoz.matte at oracle.com>; 2d-dev at openjdk.java.net
> >> Subject: Re: [OpenJDK 2D-Dev] [8u] RFR: 8212914: Test
> >> javax/imageio/plugins/bmp/BMP8BPPLoadTest.java fails
> >>
> >> Hi Fairoz,
> >>
> >> I do not see ImageIO.read and ImageIO.createImageInputStream
> throwing
> >> IOB exception in the spec, it throws IOException so I guess there's
> >> no point catching IOB.
> > This test case has been added as part of "JDK-8182461:
> IndexOutOfBoundsException when reading indexed color BMP"
> > Due to missing "break" IOB exception was generated.
> >
> >> Also, you need to add this bugid to @bug tag and also remove @author
> >> tag which we do not recommend now. Also, can you please indent byte[]
> data ?
> > Yes updated all, here is the updated webrev.
> > http://cr.openjdk.java.net/~fmatte/8212914/webrev.02/
> >
> > Thanks,
> > Fairoz
> >> Regards
> >> Prasanta
> >> On 26-Oct-18 10:03 PM, Fairoz Matte wrote:
> >>> Hi Prasanta,
> >>>
> >>> Thanks for looking into it.
> >>>
> >>>> -----Original Message-----
> >>>> From: Prasanta Sadhukhan
> >>>> Sent: Friday, October 26, 2018 8:56 AM
> >>>> To: Fairoz Matte <fairoz.matte at oracle.com>; 2d-
> dev at openjdk.java.net
> >>>> Subject: Re: [OpenJDK 2D-Dev] [8u] RFR: 8212914: Test
> >>>> javax/imageio/plugins/bmp/BMP8BPPLoadTest.java fails
> >>>>
> >>>> Hi Fairoz,
> >>>>
> >>>> Do you know if the bmp image file has Oracle copyright? If not, you
> >>>> cannot check it in.
> >>> I was not aware of it. Yes image file is not Oracle copyright compliant.
> >>>
> >>>> Alternatively, you may get a hexdump of the bmp file and create a
> >>>> byte[] array with that hex data and create ByteArrayInputStream
> >>>> with that and use that for ImageIO as an ImageInputStream.
> >>> Yes it is good approach, here is the updated webrev
> >>> http://cr.openjdk.java.net/~fmatte/8212914/webrev.01/
> >>>
> >>> Thanks,
> >>> Fairoz
> >>>> Regards
> >>>> Prasanta
> >>>> On 25-Oct-18 11:52 AM, Fairoz Matte wrote:
> >>>>> Hi,
> >>>>>
> >>>>> Kindly review the small fix.
> >>>>>
> >>>>> Background:
> >>>>> "javax/imageio/plugins/bmp/BMP8BPPLoadTest.java test case" has
> >> been
> >>>>> added part of JDK-8182461, Test case has a dependency on input
> >>>>> file
> >>>> "BMP8BPPLoadTest.PNG", during push this was missed.
> >>>>> In this fix test case also modified to refer the input file from
> >>>>> same directory
> >>>>>
> >>>>> JBS bug - https://bugs.openjdk.java.net/browse/JDK-8212914
> >>>>> Webrev - http://cr.openjdk.java.net/~fmatte/8212914/webrev.00/
> >>>>>
> >>>>> Thanks,
> >>>>> Fairoz
> >>>>>
> >>>>>
> 

From jayathirth.d.v at oracle.com  Tue Oct 30 08:43:20 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Tue, 30 Oct 2018 01:43:20 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] [12] RFR JDK-8213130: Update ProblemList after
 verification of jtreg tests in Win 7
Message-ID: <f690e400-9b97-4370-b75a-077d60c5e8f4@default>

Hello All,

 

Please review the following fix in JDK 12:

 

Bug : https://bugs.openjdk.java.net/browse/JDK-8213130 

Webrev : http://cr.openjdk.java.net/~jdv/8213130/webrev.00/

 

These are the test failures/errors which happen when they are run individually.

All the failures/erros are happening in both Win 7 & 10, except java/awt/font/FontNames/LocaleFamilyNames.java which throws error only in Win 7.

 

Thanks,

Jay

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181030/2fdc1cf0/attachment.html>

From prasanta.sadhukhan at oracle.com  Tue Oct 30 09:19:49 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 30 Oct 2018 14:49:49 +0530
Subject: [OpenJDK 2D-Dev] <Swing Dev> [12] RFR JDK-8213130: Update
 ProblemList after verification of jtreg tests in Win 7
In-Reply-To: <f690e400-9b97-4370-b75a-077d60c5e8f4@default>
References: <f690e400-9b97-4370-b75a-077d60c5e8f4@default>
Message-ID: <09824ba1-ae0a-52bb-8839-fb55bd95acc5@oracle.com>

looks ok.

Regards
Prasanta
On 30-Oct-18 2:13 PM, Jayathirth D V wrote:
>
> Hello All,
>
> Please review the following fix in JDK 12:
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8213130
>
> Webrev : http://cr.openjdk.java.net/~jdv/8213130/webrev.00/ 
> <http://cr.openjdk.java.net/%7Ejdv/8213130/webrev.00/>
>
> These are the test failures/errors which happen when they are run 
> individually.
>
> All the failures/erros are happening in both Win 7 & 10, except 
> java/awt/font/FontNames/LocaleFamilyNames.java which throws error only 
> in Win 7.
>
> Thanks,
>
> Jay
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181030/c549b975/attachment.html>

From jayathirth.d.v at oracle.com  Tue Oct 30 09:31:12 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Tue, 30 Oct 2018 02:31:12 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] [8u] RFR: 8212914: Test
 javax/imageio/plugins/bmp/BMP8BPPLoadTest.java fails
In-Reply-To: <4e5adc69-99af-4623-9835-837efb74cf7c@default>
References: <cf9eb16a-993c-4767-a993-eafe9313f0d1@default>
 <e843aa6f-73f5-a06d-70c0-94190282ce8d@oracle.com>
 <01a3ef25-4475-46d6-9bd2-bf41db6e5845@default>
 <dae481e0-52a4-6626-7d2a-6674c7cc3a43@oracle.com>
 <6164ba88-a412-46dc-8c09-3ba77b60fc32@default>
 <9158867f-58a3-0449-5fac-3e5122380940@oracle.com>
 <4e5adc69-99af-4623-9835-837efb74cf7c@default>
Message-ID: <1d18c933-d144-4677-8d81-29bf936b5ced@default>

Hi Fairoz,

@requires tag usage in jtreg : https://openjdk.java.net/jtreg/tag-spec.html#requires_names 
I think jtreg tag doesn?t support mentioning input file. Also I don?t know why it was mentioned as "@requires BMP8BPPLoadTest.PNG" when input file in code was "new File("BMP8BPPLoadTest.bmp")".

Anyway since we are using stream there will be no file input issues.
Apart from what Prasanta has mentioned over webrev.02, please remove println statements from test case before pushing.

Changes are fine.

Thanks,
Jay

-----Original Message-----
From: Fairoz Matte 
Sent: Tuesday, October 30, 2018 1:33 PM
To: Prasanta Sadhukhan; 2d-dev at openjdk.java.net
Subject: Re: [OpenJDK 2D-Dev] [8u] RFR: 8212914: Test javax/imageio/plugins/bmp/BMP8BPPLoadTest.java fails

Thanks Prasanta,

I will update that, need one more review on this?

Thanks,
Fairoz

> -----Original Message-----
> From: Prasanta Sadhukhan
> Sent: Tuesday, October 30, 2018 12:24 PM
> To: Fairoz Matte <fairoz.matte at oracle.com>; 2d-dev at openjdk.java.net
> Subject: Re: [OpenJDK 2D-Dev] [8u] RFR: 8212914: Test 
> javax/imageio/plugins/bmp/BMP8BPPLoadTest.java fails
> 
> Hi Fairoz,
> 
> @bug tag should not spearate bugs by commas, just by spaces. other 
> than that, looks ok to me.
> 
> Regards
> Prasanta
> On 30-Oct-18 10:13 AM, Fairoz Matte wrote:
> > Hi Prasanta,
> >
> >> -----Original Message-----
> >> From: Prasanta Sadhukhan
> >> Sent: Monday, October 29, 2018 12:18 PM
> >> To: Fairoz Matte <fairoz.matte at oracle.com>; 2d-dev at openjdk.java.net
> >> Subject: Re: [OpenJDK 2D-Dev] [8u] RFR: 8212914: Test 
> >> javax/imageio/plugins/bmp/BMP8BPPLoadTest.java fails
> >>
> >> Hi Fairoz,
> >>
> >> I do not see ImageIO.read and ImageIO.createImageInputStream
> throwing
> >> IOB exception in the spec, it throws IOException so I guess there's 
> >> no point catching IOB.
> > This test case has been added as part of "JDK-8182461:
> IndexOutOfBoundsException when reading indexed color BMP"
> > Due to missing "break" IOB exception was generated.
> >
> >> Also, you need to add this bugid to @bug tag and also remove 
> >> @author tag which we do not recommend now. Also, can you please 
> >> indent byte[]
> data ?
> > Yes updated all, here is the updated webrev.
> > http://cr.openjdk.java.net/~fmatte/8212914/webrev.02/
> >
> > Thanks,
> > Fairoz
> >> Regards
> >> Prasanta
> >> On 26-Oct-18 10:03 PM, Fairoz Matte wrote:
> >>> Hi Prasanta,
> >>>
> >>> Thanks for looking into it.
> >>>
> >>>> -----Original Message-----
> >>>> From: Prasanta Sadhukhan
> >>>> Sent: Friday, October 26, 2018 8:56 AM
> >>>> To: Fairoz Matte <fairoz.matte at oracle.com>; 2d-
> dev at openjdk.java.net
> >>>> Subject: Re: [OpenJDK 2D-Dev] [8u] RFR: 8212914: Test 
> >>>> javax/imageio/plugins/bmp/BMP8BPPLoadTest.java fails
> >>>>
> >>>> Hi Fairoz,
> >>>>
> >>>> Do you know if the bmp image file has Oracle copyright? If not, 
> >>>> you cannot check it in.
> >>> I was not aware of it. Yes image file is not Oracle copyright compliant.
> >>>
> >>>> Alternatively, you may get a hexdump of the bmp file and create a 
> >>>> byte[] array with that hex data and create ByteArrayInputStream 
> >>>> with that and use that for ImageIO as an ImageInputStream.
> >>> Yes it is good approach, here is the updated webrev 
> >>> http://cr.openjdk.java.net/~fmatte/8212914/webrev.01/
> >>>
> >>> Thanks,
> >>> Fairoz
> >>>> Regards
> >>>> Prasanta
> >>>> On 25-Oct-18 11:52 AM, Fairoz Matte wrote:
> >>>>> Hi,
> >>>>>
> >>>>> Kindly review the small fix.
> >>>>>
> >>>>> Background:
> >>>>> "javax/imageio/plugins/bmp/BMP8BPPLoadTest.java test case" has
> >> been
> >>>>> added part of JDK-8182461, Test case has a dependency on input 
> >>>>> file
> >>>> "BMP8BPPLoadTest.PNG", during push this was missed.
> >>>>> In this fix test case also modified to refer the input file from 
> >>>>> same directory
> >>>>>
> >>>>> JBS bug - https://bugs.openjdk.java.net/browse/JDK-8212914
> >>>>> Webrev - http://cr.openjdk.java.net/~fmatte/8212914/webrev.00/
> >>>>>
> >>>>> Thanks,
> >>>>> Fairoz
> >>>>>
> >>>>>
> 

From prasanta.sadhukhan at oracle.com  Tue Oct 30 09:58:11 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 30 Oct 2018 15:28:11 +0530
Subject: [OpenJDK 2D-Dev] [12] RFR JDK-8213138: Update ProblemList.txt for
	mac
Message-ID: <b374a214-66ca-0973-1f4f-7e217b0951f9@oracle.com>

Hi All,

Please review an updation of ProblemList for mac jtreg run.

Following tests were added in ProblemList. With this addition, mac10.13 
jtreg run shows no failures/errors.

java/awt/Window/MainKeyWindowTest/TestMainKeyWindow.java: JDK-8213126 
<https://bugs.openjdk.java.net/browse/JDK-8213126>
javax/swing/JTree/6263446/bug6263446.java: JDK-8213125 
<https://bugs.openjdk.java.net/browse/JDK-8213125>
javax/swing/JEditorPane/6917744/bug6917744.java JDK-8213124 
<https://bugs.openjdk.java.net/browse/JDK-8213124>
javax/swing/JButton/4368790/bug4368790.java JDK-8213123 
<https://bugs.openjdk.java.net/browse/JDK-8213123>
javax/swing/GraphicsConfigNotifier/StalePreferredSize.java JDK-8213121 
<https://bugs.openjdk.java.net/browse/JDK-8213121>
java/awt/TextArea/AutoScrollOnSelectAndAppend/AutoScrollOnSelectAndAppend.java 
JDK-8213120 <https://bugs.openjdk.java.net/browse/JDK-8213120>
java/awt/GraphicsDevice/CheckDisplayModes.java JDK-8213119 
<https://bugs.openjdk.java.net/browse/JDK-8213119>

Bug: https://bugs.openjdk.java.net/browse/JDK-8213138
webrev: http://cr.openjdk.java.net/~psadhukhan/8213138/webrev/

Regards
Prasanta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181030/a0b751bd/attachment.html>

From jayathirth.d.v at oracle.com  Tue Oct 30 10:09:47 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Tue, 30 Oct 2018 03:09:47 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] <Swing Dev> [12] RFR JDK-8213138: Update
	ProblemList.txt for mac
In-Reply-To: <b374a214-66ca-0973-1f4f-7e217b0951f9@oracle.com>
References: <b374a214-66ca-0973-1f4f-7e217b0951f9@oracle.com>
Message-ID: <0337c7ff-11f3-434a-a08d-d0f0d97bb77f@default>

Changes are fine.

?

Regards,

Jay

?

From: Prasanta Sadhukhan 
Sent: Tuesday, October 30, 2018 3:28 PM
To: awt-dev at openjdk.java.net; swing-dev at openjdk.java.net; 2d-dev
Subject: <Swing Dev> [12] RFR JDK-8213138: Update ProblemList.txt for mac

?

Hi All,

Please review an updation of ProblemList for mac jtreg run.

Following tests were added in ProblemList. With this addition, mac10.13 jtreg run shows no failures/errors.

java/awt/Window/MainKeyWindowTest/TestMainKeyWindow.java: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8213126"JDK-8213126 
javax/swing/JTree/6263446/bug6263446.java: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8213125"JDK-8213125 
javax/swing/JEditorPane/6917744/bug6917744.java HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8213124"JDK-8213124 
javax/swing/JButton/4368790/bug4368790.java HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8213123"JDK-8213123 
javax/swing/GraphicsConfigNotifier/StalePreferredSize.java HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8213121"JDK-8213121 
java/awt/TextArea/AutoScrollOnSelectAndAppend/AutoScrollOnSelectAndAppend.java HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8213120"JDK-8213120 
java/awt/GraphicsDevice/CheckDisplayModes.java HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8213119"JDK-8213119

Bug: https://bugs.openjdk.java.net/browse/JDK-8213138
webrev: http://cr.openjdk.java.net/~psadhukhan/8213138/webrev/

Regards
Prasanta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181030/1676fdf1/attachment-0001.html>

From fairoz.matte at oracle.com  Tue Oct 30 12:47:18 2018
From: fairoz.matte at oracle.com (Fairoz Matte)
Date: Tue, 30 Oct 2018 05:47:18 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] [8u] RFR: 8212914: Test
 javax/imageio/plugins/bmp/BMP8BPPLoadTest.java fails
In-Reply-To: <1d18c933-d144-4677-8d81-29bf936b5ced@default>
References: <cf9eb16a-993c-4767-a993-eafe9313f0d1@default>
 <e843aa6f-73f5-a06d-70c0-94190282ce8d@oracle.com>
 <01a3ef25-4475-46d6-9bd2-bf41db6e5845@default>
 <dae481e0-52a4-6626-7d2a-6674c7cc3a43@oracle.com>
 <6164ba88-a412-46dc-8c09-3ba77b60fc32@default>
 <9158867f-58a3-0449-5fac-3e5122380940@oracle.com>
 <4e5adc69-99af-4623-9835-837efb74cf7c@default>
 <1d18c933-d144-4677-8d81-29bf936b5ced@default>
Message-ID: <132381e6-df0f-47ba-9803-3322d2921ded@default>

Hi Jay,

Thanks for the review.

> -----Original Message-----
> From: Jayathirth D V
> Sent: Tuesday, October 30, 2018 3:01 PM
> To: Fairoz Matte <fairoz.matte at oracle.com>; Prasanta Sadhukhan
> <prasanta.sadhukhan at oracle.com>; 2d-dev at openjdk.java.net
> Subject: RE: [OpenJDK 2D-Dev] [8u] RFR: 8212914: Test
> javax/imageio/plugins/bmp/BMP8BPPLoadTest.java fails
> 
> Hi Fairoz,
> 
> @requires tag usage in jtreg : https://openjdk.java.net/jtreg/tag-
> spec.html#requires_names
> I think jtreg tag doesn?t support mentioning input file. Also I don?t know why
> it was mentioned as "@requires BMP8BPPLoadTest.PNG" when input file in
> code was "new File("BMP8BPPLoadTest.bmp")".

"@requires BMP8BPPLoadTest.PNG", has been removed since webrev.00.

> 
> Anyway since we are using stream there will be no file input issues.
> Apart from what Prasanta has mentioned over webrev.02, please remove
> println statements from test case before pushing.

Sure, I will do that, thanks for the review.

Below is the final webrev with updated changes (suggested by you and Prasanta)
http://cr.openjdk.java.net/~fmatte/8212914/webrev.03/ 

Thanks,
Fairoz
> 
> Changes are fine.
> 
> Thanks,
> Jay
> 
> -----Original Message-----
> From: Fairoz Matte
> Sent: Tuesday, October 30, 2018 1:33 PM
> To: Prasanta Sadhukhan; 2d-dev at openjdk.java.net
> Subject: Re: [OpenJDK 2D-Dev] [8u] RFR: 8212914: Test
> javax/imageio/plugins/bmp/BMP8BPPLoadTest.java fails
> 
> Thanks Prasanta,
> 
> I will update that, need one more review on this?
> 
> Thanks,
> Fairoz
> 
> > -----Original Message-----
> > From: Prasanta Sadhukhan
> > Sent: Tuesday, October 30, 2018 12:24 PM
> > To: Fairoz Matte <fairoz.matte at oracle.com>; 2d-dev at openjdk.java.net
> > Subject: Re: [OpenJDK 2D-Dev] [8u] RFR: 8212914: Test
> > javax/imageio/plugins/bmp/BMP8BPPLoadTest.java fails
> >
> > Hi Fairoz,
> >
> > @bug tag should not spearate bugs by commas, just by spaces. other
> > than that, looks ok to me.
> >
> > Regards
> > Prasanta
> > On 30-Oct-18 10:13 AM, Fairoz Matte wrote:
> > > Hi Prasanta,
> > >
> > >> -----Original Message-----
> > >> From: Prasanta Sadhukhan
> > >> Sent: Monday, October 29, 2018 12:18 PM
> > >> To: Fairoz Matte <fairoz.matte at oracle.com>; 2d-
> dev at openjdk.java.net
> > >> Subject: Re: [OpenJDK 2D-Dev] [8u] RFR: 8212914: Test
> > >> javax/imageio/plugins/bmp/BMP8BPPLoadTest.java fails
> > >>
> > >> Hi Fairoz,
> > >>
> > >> I do not see ImageIO.read and ImageIO.createImageInputStream
> > throwing
> > >> IOB exception in the spec, it throws IOException so I guess there's
> > >> no point catching IOB.
> > > This test case has been added as part of "JDK-8182461:
> > IndexOutOfBoundsException when reading indexed color BMP"
> > > Due to missing "break" IOB exception was generated.
> > >
> > >> Also, you need to add this bugid to @bug tag and also remove
> > >> @author tag which we do not recommend now. Also, can you please
> > >> indent byte[]
> > data ?
> > > Yes updated all, here is the updated webrev.
> > > http://cr.openjdk.java.net/~fmatte/8212914/webrev.02/
> > >
> > > Thanks,
> > > Fairoz
> > >> Regards
> > >> Prasanta
> > >> On 26-Oct-18 10:03 PM, Fairoz Matte wrote:
> > >>> Hi Prasanta,
> > >>>
> > >>> Thanks for looking into it.
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Prasanta Sadhukhan
> > >>>> Sent: Friday, October 26, 2018 8:56 AM
> > >>>> To: Fairoz Matte <fairoz.matte at oracle.com>; 2d-
> > dev at openjdk.java.net
> > >>>> Subject: Re: [OpenJDK 2D-Dev] [8u] RFR: 8212914: Test
> > >>>> javax/imageio/plugins/bmp/BMP8BPPLoadTest.java fails
> > >>>>
> > >>>> Hi Fairoz,
> > >>>>
> > >>>> Do you know if the bmp image file has Oracle copyright? If not,
> > >>>> you cannot check it in.
> > >>> I was not aware of it. Yes image file is not Oracle copyright compliant.
> > >>>
> > >>>> Alternatively, you may get a hexdump of the bmp file and create a
> > >>>> byte[] array with that hex data and create ByteArrayInputStream
> > >>>> with that and use that for ImageIO as an ImageInputStream.
> > >>> Yes it is good approach, here is the updated webrev
> > >>> http://cr.openjdk.java.net/~fmatte/8212914/webrev.01/
> > >>>
> > >>> Thanks,
> > >>> Fairoz
> > >>>> Regards
> > >>>> Prasanta
> > >>>> On 25-Oct-18 11:52 AM, Fairoz Matte wrote:
> > >>>>> Hi,
> > >>>>>
> > >>>>> Kindly review the small fix.
> > >>>>>
> > >>>>> Background:
> > >>>>> "javax/imageio/plugins/bmp/BMP8BPPLoadTest.java test case" has
> > >> been
> > >>>>> added part of JDK-8182461, Test case has a dependency on input
> > >>>>> file
> > >>>> "BMP8BPPLoadTest.PNG", during push this was missed.
> > >>>>> In this fix test case also modified to refer the input file from
> > >>>>> same directory
> > >>>>>
> > >>>>> JBS bug - https://bugs.openjdk.java.net/browse/JDK-8212914
> > >>>>> Webrev - http://cr.openjdk.java.net/~fmatte/8212914/webrev.00/
> > >>>>>
> > >>>>> Thanks,
> > >>>>> Fairoz
> > >>>>>
> > >>>>>
> >

From philip.race at oracle.com  Tue Oct 30 16:59:57 2018
From: philip.race at oracle.com (Phil Race)
Date: Tue, 30 Oct 2018 09:59:57 -0700
Subject: [OpenJDK 2D-Dev] [12] Review Request: 8211992
 GraphicsConfiguration.getDevice().getDisplayMode() causes JVM crash on Mac
In-Reply-To: <92a3b11d-6734-7aeb-0520-7ae0279d24a9@oracle.com>
References: <92a3b11d-6734-7aeb-0520-7ae0279d24a9@oracle.com>
Message-ID: <87dbe59f-7259-6d62-b7f7-1dc5b796df09@oracle.com>

Looks reasonable. A test is difficult, but I presume you did some testing.
Can you report the scenarios you tested and on which OS version ?
eg,

Did you try remove/add/remove, or add/remove/add ?
Did you try wake from sleep ?
Did you try removing a monitor whilst it was sleeping and then waking ?

All whilst a Java app was running of course - on the monitor being removed.

-phil.

On 10/15/18 6:11 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk 12.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8211992
> Webrev: http://cr.openjdk.java.net/~serb/8211992/webrev.00
>
> Short description:
> ? The root cause is how we use CoreGraphics display ID. This 
> identifier can become non-valid at any time therefore methods, which 
> is using this id should be ready to it. And this bug found a few 
> places which does not take care about the rule above.
>
> Long description:
> ? In the CGraphicsDevice class we maintain the ID for the native 
> screen. This ID usually changed when the user adds/removes monitors to 
> the system. Since using invalid id can cause NULL result in the native 
> code we tries to workaround it by two steps:
>
> ? Step (1) If the monitor is removed from the system, then we reassign 
> its displayid to the primary screen. So if the user will holds the 
> reference to this GDevice, it will use the MainDisplay. But note that 
> if the user will remove the main screen again then the old screen, 
> which were removed previously, will not be updated(but will use an 
> invalid displayid).
>
> ? Step (2) Some of the native methods in CGraphicsDevice class are 
> ready to NULL and provide some meaningful defaults, like 72 dpi. But 
> some others methods are not ready for that, like 
> nativeGetDisplayMode/etc.
>
> Fix description:
> ?- I have minimized/dropped the usage of displayid outside of 
> CGraphicsDevice class, in CRobot it was unused, and the code from 
> CGraphicsConfig.m was moved to CGraphicsDevice.m.
> ?- In CGraphicsEnvironment class we now maintain the list of old 
> devices, which is updated for all _displayReconfiguration events. This 
> is the same implementation as on windows in Win32GraphicsEnvironment.java
> ?- I have added some default values to all native methods also. Just 
> to cover the rare case when we call the method and displayid became 
> invalid at the same moment.
>


From Sergey.Bylokhov at oracle.com  Tue Oct 30 22:57:52 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 30 Oct 2018 15:57:52 -0700
Subject: [OpenJDK 2D-Dev] <Swing Dev> [12] RFR JDK-8213138: Update
	ProblemList.txt for mac
In-Reply-To: <b374a214-66ca-0973-1f4f-7e217b0951f9@oracle.com>
References: <b374a214-66ca-0973-1f4f-7e217b0951f9@oracle.com>
Message-ID: <629ea955-5df7-16bd-59a4-557c786b323f@oracle.com>

Hi, Prasanta.
On 30/10/2018 02:58, Prasanta Sadhukhan wrote:
> java/awt/Window/MainKeyWindowTest/TestMainKeyWindow.java: JDK-8213126 <https://bugs.openjdk.java.net/browse/JDK-8213126>

The failure of the TestMainKeyWindow.java is not a bug, you need to provide -nativepath to the jtreg, because this test has a native code.

> javax/swing/JTree/6263446/bug6263446.java: JDK-8213125 <https://bugs.openjdk.java.net/browse/JDK-8213125>
> javax/swing/JEditorPane/6917744/bug6917744.java JDK-8213124 <https://bugs.openjdk.java.net/browse/JDK-8213124>
> javax/swing/JButton/4368790/bug4368790.java JDK-8213123 <https://bugs.openjdk.java.net/browse/JDK-8213123>
> javax/swing/GraphicsConfigNotifier/StalePreferredSize.java JDK-8213121 <https://bugs.openjdk.java.net/browse/JDK-8213121>
> java/awt/TextArea/AutoScrollOnSelectAndAppend/AutoScrollOnSelectAndAppend.java JDK-8213120 <https://bugs.openjdk.java.net/browse/JDK-8213120>
> java/awt/GraphicsDevice/CheckDisplayModes.java JDK-8213119 <https://bugs.openjdk.java.net/browse/JDK-8213119>
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8213138
> webrev: http://cr.openjdk.java.net/~psadhukhan/8213138/webrev/
> 
> Regards
> Prasanta


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Wed Oct 31 02:46:25 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 30 Oct 2018 19:46:25 -0700
Subject: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11
In-Reply-To: <CAKjRUT6gaRGTtSOCxDCrgoMx4Fva3MMResVrZJge+_umEd6CHQ@mail.gmail.com>
References: <CAK9Gx1fx=w29r1BSCYwBsxqe6SMKTMpQPj30xb0-5F+0nsudMg@mail.gmail.com>
 <CAKjRUT6fe+SLCO0aHXQm76CrLZJfxfK6vG6d5ZXZaB4ocEm-GA@mail.gmail.com>
 <CAK9Gx1fUrrsPTug5n0fNGEkJ=_J8L2JAqubZtNNuNL9ZaS3KxQ@mail.gmail.com>
 <CAK9Gx1czsrxtuVUo_sCbY6LR3W2wTLbgOo6TOPWZY0vEyKhtUQ@mail.gmail.com>
 <5BBE1D8D.6040806@oracle.com>
 <CAK9Gx1c81CEgz4_EnsLeP0WXu82rfsWed-iYWqhtn12fJy+wrA@mail.gmail.com>
 <CAKjRUT61HwGRuUnU6D8WA8C1nMQr9tBVuKyLtAgyHtNKJJU=hw@mail.gmail.com>
 <CAK9Gx1dvB=rBoN99zUewSBGNjpthoBQi+AyzmQbFnv-cE7wY2Q@mail.gmail.com>
 <a7abd67d-b72c-ceb1-7d7e-78df32600394@oracle.com>
 <CAKjRUT7Odx3xaYykCRPbWLTHqc6AEV59wHjeQGCp4_41FYNvSQ@mail.gmail.com>
 <CAKjRUT6VUUPg+OqCgQbJWCBoaqyYYU72CY7iQadWh0zWpj0=Dg@mail.gmail.com>
 <5BC0B18A.90300@oracle.com>
 <CAKjRUT61cgGX9v9HqZ=nhN5tZ_iADZMO5dGTHLduANFJ_VQBOw@mail.gmail.com>
 <CAKjRUT5Raxjb5HwCqQOUUEmwvF-48Urk7Rv95eC2dAT3WM4OHQ@mail.gmail.com>
 <e64cb30c-a10c-5269-6f99-0874e6d6fbe9@oracle.com>
 <CAKjRUT6gaRGTtSOCxDCrgoMx4Fva3MMResVrZJge+_umEd6CHQ@mail.gmail.com>
Message-ID: <7adb1b09-d700-f44b-5dcd-aea2a06bf40c@oracle.com>

On 26/10/2018 00:41, Laurent Bourg?s wrote:
> I suppose a JEP or RFE is required, isnt it ?

It depends from the changes, but such contributions are welcome!

> 
> Cheers,
> Laurent
> 
> 
>     On 23/10/2018 13:37, Laurent Bourg?s wrote:
>      > Phil,
>      > I quickly modified the final update & sort loop to:
>      > - move sort in another block
>      > - use qsort() using a new comparator sortSegmentsByCurX
>      >
>      > This improves performance in PolyLineTest by 3 times: ~1s vs 3.5s !
>      > Apparently qsort() is not optimal (comparator can not be inlined by c) so it may explain why Marlin (0x0 sampling) is still 2 times faster with its custom merge-sort (in-place).
>      >
>      > Any idea to improve C sort ?
>      > Is it good enough ?
>      >
>      > - USE_QSORT_X: 1
>      > oct. 23, 2018 10:15:29 PM polylinetest.Canvas paintComponent
>      > INFOS: Paint Time: 1,081s
>      > INFOS: Paint Time: 1,058s
>      > INFOS: Paint Time: 1,067s
>      >
>      > - USE_QSORT_X: 0
>      > oct. 23, 2018 10:18:50 PM polylinetest.Canvas paintComponent
>      > INFOS: Paint Time: 3,318s
>      > INFOS: Paint Time: 3,258s
>      > INFOS: Paint Time: 3,273s
>      >
>      > Patch:
>      > diff -r 297450fcab26 src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c
>      > --- a/src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c??? Tue Oct 16 23:21:05 2018 +0530
>      > +++ b/src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c??? Tue Oct 23 22:31:00 2018 +0200
>      > @@ -1243,6 +1243,18 @@
>      >? ???? }
>      >? ?}
>      >
>      > +/* LBO: enable (1) / disable (0) qsort on curx */
>      > +#define USE_QSORT_X (0)
>      > +
>      > +static int CDECL
>      > +sortSegmentsByCurX(const void *elem1, const void *elem2)
>      > +{
>      > +??? jint x1 = (*(segmentData **)elem1)->curx;
>      > +??? jint x2 = (*(segmentData **)elem2)->curx;
>      > +
>      > +??? return (x1 - x2);
>      > +}
>      > +
>      >? ?static jboolean
>      >? ?ShapeSINextSpan(void *state, jint spanbox[])
>      >? ?{
>      > @@ -1378,16 +1390,28 @@
>      >? ???????????? seg->curx = x0;
>      >? ???????????? seg->cury = y0;
>      >? ???????????? seg->error = err;
>      > +??????? }
>      >
>      > -??????????? /* Then make sure the segment is sorted by x0 */
>      > -??????????? for (new = cur; new > lo; new--) {
>      > -??????????????? segmentData *seg2 = segmentTable[new - 1];
>      > -??????????????? if (seg2->curx <= x0) {
>      > -??????????????????? break;
>      > +??????? if (USE_QSORT_X && (hi - lo) > 100)
>      > +??????? {
>      > +??????????? /* use quick sort on [lo - hi] range */
>      > +??????????? qsort(&(segmentTable[lo]), (hi - lo), sizeof(segmentData *),
>      > +??????????????????? sortSegmentsByCurX);
>      > +??????? } else {
>      > +??????????? for (cur = lo; cur < hi; cur++) {
>      > +??????????????? seg = segmentTable[cur];
>      > +??????????????? x0 = seg->curx;
>      > +
>      > +??????????????? /* Then make sure the segment is sorted by x0 */
>      > +??????????????? for (new = cur; new > lo; new--) {
>      > +??????????????????? segmentData *seg2 = segmentTable[new - 1];
>      > +??????????????????? if (seg2->curx <= x0) {
>      > +??????????????????????? break;
>      > +??????????????????? }
>      > +??????????????????? segmentTable[new] = seg2;
>      >? ???????????????? }
>      > -??????????????? segmentTable[new] = seg2;
>      > +??????????????? segmentTable[new] = seg;
>      >? ???????????? }
>      > -??????????? segmentTable[new] = seg;
>      >? ???????? }
>      >? ???????? cur = lo;
>      >? ???? }
>      >
>      > Cheers,
>      > Laurent
>      >
>      > Le?mar. 23 oct. 2018 ??08:30, Laurent Bourg?s <bourges.laurent at gmail.com <mailto:bourges.laurent at gmail.com> <mailto:bourges.laurent at gmail.com <mailto:bourges.laurent at gmail.com>>> a ?crit?:
>      >
>      >? ? ?Phil,
>      >? ? ?Yesterday I started hacking ShapeSpanIterator.c to add stats: the last stage (sort by x0) is the bottleneck.
>      >? ? ?In this case every sort takes up to 15ms per pixel row !
>      >
>      >? ? ?I will see if I can adapt Marlin's MergeSort.java to C to have an efficient sort in-place.
>      >? ? ?Do you know if libawt has already an efficient sort instead of porting mine ?
>      >
>      >? ? ?PS: "To save the planet, make software more efficient" is my quote of the day !
>      >
>      >? ? ?Cheers,
>      >? ? ?Laurent
>      >
> 
> 
>     -- 
>     Best regards, Sergey.
> 


-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Wed Oct 31 05:30:51 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 31 Oct 2018 11:00:51 +0530
Subject: [OpenJDK 2D-Dev] <Swing Dev> [12] RFR JDK-8213138: Update
	ProblemList.txt for mac
In-Reply-To: <629ea955-5df7-16bd-59a4-557c786b323f@oracle.com>
References: <b374a214-66ca-0973-1f4f-7e217b0951f9@oracle.com>
 <629ea955-5df7-16bd-59a4-557c786b323f@oracle.com>
Message-ID: <01b3a323-6c41-19e1-82f8-0142ef541b8a@oracle.com>

Hi Sergey,

What is the syntax of this? I tried

-nativepath:<MainKeyWindowTest test dir>

but it gave "unexpected exit from test code"

Can we put this option in the test itself in @run option? since we do 
not run with nativepath option neither in PIT not in test sprint, it 
will always fail.

Regards
Prasanta
On 31-Oct-18 4:27 AM, Sergey Bylokhov wrote:
> Hi, Prasanta.
> On 30/10/2018 02:58, Prasanta Sadhukhan wrote:
>> java/awt/Window/MainKeyWindowTest/TestMainKeyWindow.java: JDK-8213126 
>> <https://bugs.openjdk.java.net/browse/JDK-8213126>
>
> The failure of the TestMainKeyWindow.java is not a bug, you need to 
> provide -nativepath to the jtreg, because this test has a native code.
>
>> javax/swing/JTree/6263446/bug6263446.java: JDK-8213125 
>> <https://bugs.openjdk.java.net/browse/JDK-8213125>
>> javax/swing/JEditorPane/6917744/bug6917744.java JDK-8213124 
>> <https://bugs.openjdk.java.net/browse/JDK-8213124>
>> javax/swing/JButton/4368790/bug4368790.java JDK-8213123 
>> <https://bugs.openjdk.java.net/browse/JDK-8213123>
>> javax/swing/GraphicsConfigNotifier/StalePreferredSize.java 
>> JDK-8213121 <https://bugs.openjdk.java.net/browse/JDK-8213121>
>> java/awt/TextArea/AutoScrollOnSelectAndAppend/AutoScrollOnSelectAndAppend.java 
>> JDK-8213120 <https://bugs.openjdk.java.net/browse/JDK-8213120>
>> java/awt/GraphicsDevice/CheckDisplayModes.java JDK-8213119 
>> <https://bugs.openjdk.java.net/browse/JDK-8213119>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213138
>> webrev: http://cr.openjdk.java.net/~psadhukhan/8213138/webrev/
>>
>> Regards
>> Prasanta
>
>


From Sergey.Bylokhov at oracle.com  Wed Oct 31 17:26:10 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 31 Oct 2018 10:26:10 -0700
Subject: [OpenJDK 2D-Dev] [12] Review Request: 8211992
 GraphicsConfiguration.getDevice().getDisplayMode() causes JVM crash on Mac
In-Reply-To: <87dbe59f-7259-6d62-b7f7-1dc5b796df09@oracle.com>
References: <92a3b11d-6734-7aeb-0520-7ae0279d24a9@oracle.com>
 <87dbe59f-7259-6d62-b7f7-1dc5b796df09@oracle.com>
Message-ID: <0d185eeb-df70-b4c3-fa8f-985e9ffd2037@oracle.com>

On 30/10/2018 09:59, Phil Race wrote:
> Looks reasonable. A test is difficult, but I presume you did some testing.
> Can you report the scenarios you tested and on which OS version ?
> eg,
> 
> Did you try remove/add/remove, or add/remove/add ?
> Did you try wake from sleep ?
> Did you try removing a monitor whilst it was sleeping and then waking ?

I was not able to reproduce this bug on the multimonitor config,
but in a single monitor the bug is reproduced when I switch
the user while the program is executed.

For the test purpose and to prove that the updated methods will not crash,
I have hardcoded the wrong display id at the end of the constructor
of the GraphicsDevice, and run our tests.

> 
> All whilst a Java app was running of course - on the monitor being removed.
> 
> -phil.
> 
> On 10/15/18 6:11 PM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for jdk 12.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8211992
>> Webrev: http://cr.openjdk.java.net/~serb/8211992/webrev.00
>>
>> Short description:
>> ? The root cause is how we use CoreGraphics display ID. This identifier can become non-valid at any time therefore methods, which is using this id should be ready to it. And this bug found a few places which does not take care about the rule above.
>>
>> Long description:
>> ? In the CGraphicsDevice class we maintain the ID for the native screen. This ID usually changed when the user adds/removes monitors to the system. Since using invalid id can cause NULL result in the native code we tries to workaround it by two steps:
>>
>> ? Step (1) If the monitor is removed from the system, then we reassign its displayid to the primary screen. So if the user will holds the reference to this GDevice, it will use the MainDisplay. But note that if the user will remove the main screen again then the old screen, which were removed previously, will not be updated(but will use an invalid displayid).
>>
>> ? Step (2) Some of the native methods in CGraphicsDevice class are ready to NULL and provide some meaningful defaults, like 72 dpi. But some others methods are not ready for that, like nativeGetDisplayMode/etc.
>>
>> Fix description:
>> ?- I have minimized/dropped the usage of displayid outside of CGraphicsDevice class, in CRobot it was unused, and the code from CGraphicsConfig.m was moved to CGraphicsDevice.m.
>> ?- In CGraphicsEnvironment class we now maintain the list of old devices, which is updated for all _displayReconfiguration events. This is the same implementation as on windows in Win32GraphicsEnvironment.java
>> ?- I have added some default values to all native methods also. Just to cover the rare case when we call the method and displayid became invalid at the same moment.
>>
> 


-- 
Best regards, Sergey.

From philip.race at oracle.com  Wed Oct 31 17:54:53 2018
From: philip.race at oracle.com (Phil Race)
Date: Wed, 31 Oct 2018 10:54:53 -0700
Subject: [OpenJDK 2D-Dev] [12] Review Request: 8211992
 GraphicsConfiguration.getDevice().getDisplayMode() causes JVM crash on Mac
In-Reply-To: <0d185eeb-df70-b4c3-fa8f-985e9ffd2037@oracle.com>
References: <92a3b11d-6734-7aeb-0520-7ae0279d24a9@oracle.com>
 <87dbe59f-7259-6d62-b7f7-1dc5b796df09@oracle.com>
 <0d185eeb-df70-b4c3-fa8f-985e9ffd2037@oracle.com>
Message-ID: <28b4bad3-ee4b-b0a7-b54c-0e2d3ce54e9c@oracle.com>

OK. +1.

-phil.

On 10/31/18 10:26 AM, Sergey Bylokhov wrote:
> On 30/10/2018 09:59, Phil Race wrote:
>> Looks reasonable. A test is difficult, but I presume you did some 
>> testing.
>> Can you report the scenarios you tested and on which OS version ?
>> eg,
>>
>> Did you try remove/add/remove, or add/remove/add ?
>> Did you try wake from sleep ?
>> Did you try removing a monitor whilst it was sleeping and then waking ?
>
> I was not able to reproduce this bug on the multimonitor config,
> but in a single monitor the bug is reproduced when I switch
> the user while the program is executed.
>
> For the test purpose and to prove that the updated methods will not 
> crash,
> I have hardcoded the wrong display id at the end of the constructor
> of the GraphicsDevice, and run our tests.
>
>>
>> All whilst a Java app was running of course - on the monitor being 
>> removed.
>>
>> -phil.
>>
>> On 10/15/18 6:11 PM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for jdk 12.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8211992
>>> Webrev: http://cr.openjdk.java.net/~serb/8211992/webrev.00
>>>
>>> Short description:
>>> ? The root cause is how we use CoreGraphics display ID. This 
>>> identifier can become non-valid at any time therefore methods, which 
>>> is using this id should be ready to it. And this bug found a few 
>>> places which does not take care about the rule above.
>>>
>>> Long description:
>>> ? In the CGraphicsDevice class we maintain the ID for the native 
>>> screen. This ID usually changed when the user adds/removes monitors 
>>> to the system. Since using invalid id can cause NULL result in the 
>>> native code we tries to workaround it by two steps:
>>>
>>> ? Step (1) If the monitor is removed from the system, then we 
>>> reassign its displayid to the primary screen. So if the user will 
>>> holds the reference to this GDevice, it will use the MainDisplay. 
>>> But note that if the user will remove the main screen again then the 
>>> old screen, which were removed previously, will not be updated(but 
>>> will use an invalid displayid).
>>>
>>> ? Step (2) Some of the native methods in CGraphicsDevice class are 
>>> ready to NULL and provide some meaningful defaults, like 72 dpi. But 
>>> some others methods are not ready for that, like 
>>> nativeGetDisplayMode/etc.
>>>
>>> Fix description:
>>> ?- I have minimized/dropped the usage of displayid outside of 
>>> CGraphicsDevice class, in CRobot it was unused, and the code from 
>>> CGraphicsConfig.m was moved to CGraphicsDevice.m.
>>> ?- In CGraphicsEnvironment class we now maintain the list of old 
>>> devices, which is updated for all _displayReconfiguration events. 
>>> This is the same implementation as on windows in 
>>> Win32GraphicsEnvironment.java
>>> ?- I have added some default values to all native methods also. Just 
>>> to cover the rare case when we call the method and displayid became 
>>> invalid at the same moment.
>>>
>>
>
>


From philip.race at oracle.com  Wed Oct 31 18:57:27 2018
From: philip.race at oracle.com (Phil Race)
Date: Wed, 31 Oct 2018 11:57:27 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8210863: Remove Xrandr include files from JDK
	sources
Message-ID: <deeeb934-c6a8-4382-f2b0-eab55bab2c79@oracle.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8210863
Webrev: http://cr.openjdk.java.net/~prr/8210863/

JDK imported Xrandr headers into it's source a really long time ago because
old build systems did not have it. We no longer have that problem, so we can
remove these.

I am not changing the code to remove the dynamic loading of the 
functions and
change it to compile time link against them.
We can probably do that too at a later time,? but the immediate goal is to
remove these source files since they are imported 3rd party sources.

-phil.



From Sergey.Bylokhov at oracle.com  Wed Oct 31 19:02:36 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 31 Oct 2018 12:02:36 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8210863: Remove Xrandr include files from
 JDK sources
In-Reply-To: <deeeb934-c6a8-4382-f2b0-eab55bab2c79@oracle.com>
References: <deeeb934-c6a8-4382-f2b0-eab55bab2c79@oracle.com>
Message-ID: <63a86af3-4387-2bbe-d275-894487115160@oracle.com>

Looks fine, I assume mach5 is green.

On 31/10/2018 11:57, Phil Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210863
> Webrev: http://cr.openjdk.java.net/~prr/8210863/
> 
> JDK imported Xrandr headers into it's source a really long time ago because
> old build systems did not have it. We no longer have that problem, so we can
> remove these.
> 
> I am not changing the code to remove the dynamic loading of the functions and
> change it to compile time link against them.
> We can probably do that too at a later time,? but the immediate goal is to
> remove these source files since they are imported 3rd party sources.
> 
> -phil.
> 
> 


-- 
Best regards, Sergey.

From philip.race at oracle.com  Wed Oct 31 19:17:59 2018
From: philip.race at oracle.com (Phil Race)
Date: Wed, 31 Oct 2018 12:17:59 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8210863: Remove Xrandr include files from
 JDK sources
In-Reply-To: <63a86af3-4387-2bbe-d275-894487115160@oracle.com>
References: <deeeb934-c6a8-4382-f2b0-eab55bab2c79@oracle.com>
 <63a86af3-4387-2bbe-d275-894487115160@oracle.com>
Message-ID: <c126cb2e-83d7-d66f-72a2-58678b335f30@oracle.com>

Erik has an updated devkit that is a pre-requisite for that. It is already
pushed and I tested with his patch which will make the new devkit the 
default.

So mach5 is green once Erik pushes his devkit fix which I have tested
to make sure we always have the header files on otherwise "minimally"
configured linux build systems.

Ergo, this will go in only once he has pushed his fix :
https://bugs.openjdk.java.net/browse/JDK-8210837

-phil.

On 10/31/18 12:02 PM, Sergey Bylokhov wrote:
> Looks fine, I assume mach5 is green.
>
> On 31/10/2018 11:57, Phil Race wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210863
>> Webrev: http://cr.openjdk.java.net/~prr/8210863/
>>
>> JDK imported Xrandr headers into it's source a really long time ago 
>> because
>> old build systems did not have it. We no longer have that problem, so 
>> we can
>> remove these.
>>
>> I am not changing the code to remove the dynamic loading of the 
>> functions and
>> change it to compile time link against them.
>> We can probably do that too at a later time,? but the immediate goal 
>> is to
>> remove these source files since they are imported 3rd party sources.
>>
>> -phil.
>>
>>
>
>


From Sergey.Bylokhov at oracle.com  Wed Oct 31 20:36:51 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 31 Oct 2018 13:36:51 -0700
Subject: [OpenJDK 2D-Dev] <Swing Dev> [12] RFR JDK-8213138: Update
	ProblemList.txt for mac
In-Reply-To: <01b3a323-6c41-19e1-82f8-0142ef541b8a@oracle.com>
References: <b374a214-66ca-0973-1f4f-7e217b0951f9@oracle.com>
 <629ea955-5df7-16bd-59a4-557c786b323f@oracle.com>
 <01b3a323-6c41-19e1-82f8-0142ef541b8a@oracle.com>
Message-ID: <4f178b49-888e-4589-0b1e-b40ad9781233@oracle.com>

On 30/10/2018 22:30, Prasanta Sadhukhan wrote:
> What is the syntax of this? I tried
> 
> -nativepath:<MainKeyWindowTest test dir>
> 
> but it gave "unexpected exit from test code"
> 
> Can we put this option in the test itself in @run option? since we do not run with nativepath option neither in PIT not in test sprint, it will always fail.

Before run this test, you need to compile the native part of the tests by this command:
   make test-image
and then
   make run-test TEST="java/awt/Window/MainKeyWindowTest/TestMainKeyWindow.java"

Samples are here:
http://hg.openjdk.java.net/jdk/jdk/raw-file/e38473506688/doc/testing.html

Or you can pass this option to jtreg directly:
   jtreg/bin/jtreg -nativepath:./build/macosx-x64/images/test/jdk/jtreg/native/ -jdk:./build/macosx-x64/images/jdk  open/test/jdk/java/awt/Window/MainKeyWindowTest/TestMainKeyWindow.java

The native test-image is also produced by our RE, so you can use pre-build test-image if you wish.

> 
> Regards
> Prasanta
> On 31-Oct-18 4:27 AM, Sergey Bylokhov wrote:
>> Hi, Prasanta.
>> On 30/10/2018 02:58, Prasanta Sadhukhan wrote:
>>> java/awt/Window/MainKeyWindowTest/TestMainKeyWindow.java: JDK-8213126 <https://bugs.openjdk.java.net/browse/JDK-8213126>
>>
>> The failure of the TestMainKeyWindow.java is not a bug, you need to provide -nativepath to the jtreg, because this test has a native code.
>>
>>> javax/swing/JTree/6263446/bug6263446.java: JDK-8213125 <https://bugs.openjdk.java.net/browse/JDK-8213125>
>>> javax/swing/JEditorPane/6917744/bug6917744.java JDK-8213124 <https://bugs.openjdk.java.net/browse/JDK-8213124>
>>> javax/swing/JButton/4368790/bug4368790.java JDK-8213123 <https://bugs.openjdk.java.net/browse/JDK-8213123>
>>> javax/swing/GraphicsConfigNotifier/StalePreferredSize.java JDK-8213121 <https://bugs.openjdk.java.net/browse/JDK-8213121>
>>> java/awt/TextArea/AutoScrollOnSelectAndAppend/AutoScrollOnSelectAndAppend.java JDK-8213120 <https://bugs.openjdk.java.net/browse/JDK-8213120>
>>> java/awt/GraphicsDevice/CheckDisplayModes.java JDK-8213119 <https://bugs.openjdk.java.net/browse/JDK-8213119>
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213138
>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8213138/webrev/
>>>
>>> Regards
>>> Prasanta
>>
>>
> 


-- 
Best regards, Sergey.