From Sergey.Bylokhov at oracle.com  Mon Jul  2 16:11:25 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 2 Jul 2018 09:11:25 -0700
Subject: [OpenJDK 2D-Dev] [11] Review Request: 8201611 Broken links in
	java.desktop javadoc
Message-ID: <6db4c190-c358-4f7e-a52d-2205a389f7d7@oracle.com>

Hello.
Please review the fix for jdk11.

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

Some links in the javadoc became broken after modules were added.

-- 
Best regards, Sergey.

From philip.race at oracle.com  Mon Jul  2 16:29:20 2018
From: philip.race at oracle.com (Phil Race)
Date: Mon, 2 Jul 2018 09:29:20 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> [11] Review Request: 8201611 Broken
 links in java.desktop javadoc
In-Reply-To: <6db4c190-c358-4f7e-a52d-2205a389f7d7@oracle.com>
References: <6db4c190-c358-4f7e-a52d-2205a389f7d7@oracle.com>
Message-ID: <a62a868b-6f4e-6de3-d786-984c24712ad6@oracle.com>


 > Some links in the javadoc became broken after modules were added

Not exactly, it was after javadoc was changed under
https://bugs.openjdk.java.net/browse/JDK-8195795

There are lot of broken links. I also have :
https://bugs.openjdk.java.net/browse/JDK-8205646

This one seems to be different than the other two .. no mention of the 
module
http://cr.openjdk.java.net/~serb/8201611/webrev.00/src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadataNode.java.udiff.html

Why is it correct ?

-phil.


On 07/02/2018 09:11 AM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk11.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201611
> Webrev: http://cr.openjdk.java.net/~serb/8201611/webrev.00
>
> Some links in the javadoc became broken after modules were added.
>


From Sergey.Bylokhov at oracle.com  Mon Jul  2 17:09:28 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 2 Jul 2018 10:09:28 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> [11] Review Request: 8201611 Broken
 links in java.desktop javadoc
In-Reply-To: <a62a868b-6f4e-6de3-d786-984c24712ad6@oracle.com>
References: <6db4c190-c358-4f7e-a52d-2205a389f7d7@oracle.com>
 <a62a868b-6f4e-6de3-d786-984c24712ad6@oracle.com>
Message-ID: <e9d74231-cee5-c20c-7745-15efb2d40bba@oracle.com>

On 02/07/2018 09:29, Phil Race wrote:
> Not exactly, it was after javadoc was changed under
> https://bugs.openjdk.java.net/browse/JDK-8195795

So modules are added to the path.

> This one seems to be different than the other two .. no mention of the 
> module
> http://cr.openjdk.java.net/~serb/8201611/webrev.00/src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadataNode.java.udiff.html 

The html tag <a> was replaced by the direct javadoc link to the java class.

> Why is it correct ?
> 
> -phil.
> 
> 
> On 07/02/2018 09:11 AM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for jdk11.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201611
>> Webrev: http://cr.openjdk.java.net/~serb/8201611/webrev.00
>>
>> Some links in the javadoc became broken after modules were added.
>>
> 


-- 
Best regards, Sergey.

From philip.race at oracle.com  Mon Jul  2 17:16:01 2018
From: philip.race at oracle.com (Phil Race)
Date: Mon, 2 Jul 2018 10:16:01 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> [11] Review Request: 8201611 Broken
 links in java.desktop javadoc
In-Reply-To: <e9d74231-cee5-c20c-7745-15efb2d40bba@oracle.com>
References: <6db4c190-c358-4f7e-a52d-2205a389f7d7@oracle.com>
 <a62a868b-6f4e-6de3-d786-984c24712ad6@oracle.com>
 <e9d74231-cee5-c20c-7745-15efb2d40bba@oracle.com>
Message-ID: <869f7602-d9dd-b266-e392-f06456036e6b@oracle.com>


OK, +1

-phil.

On 07/02/2018 10:09 AM, Sergey Bylokhov wrote:
> On 02/07/2018 09:29, Phil Race wrote:
>> Not exactly, it was after javadoc was changed under
>> https://bugs.openjdk.java.net/browse/JDK-8195795
>
> So modules are added to the path.
>
>> This one seems to be different than the other two .. no mention of 
>> the module
>> http://cr.openjdk.java.net/~serb/8201611/webrev.00/src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadataNode.java.udiff.html 
>
>
> The html tag <a> was replaced by the direct javadoc link to the java 
> class.
>
>> Why is it correct ?
>>
>> -phil.
>>
>>
>> On 07/02/2018 09:11 AM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for jdk11.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201611
>>> Webrev: http://cr.openjdk.java.net/~serb/8201611/webrev.00
>>>
>>> Some links in the javadoc became broken after modules were added.
>>>
>>
>
>


From krishna.addepalli at oracle.com  Tue Jul  3 03:44:06 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Mon, 2 Jul 2018 20:44:06 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] <AWT Dev> [11] Review Request: 8201611 Broken
 links in java.desktop javadoc
In-Reply-To: <869f7602-d9dd-b266-e392-f06456036e6b@oracle.com>
References: <6db4c190-c358-4f7e-a52d-2205a389f7d7@oracle.com>
 <a62a868b-6f4e-6de3-d786-984c24712ad6@oracle.com>
 <e9d74231-cee5-c20c-7745-15efb2d40bba@oracle.com>
 <869f7602-d9dd-b266-e392-f06456036e6b@oracle.com>
Message-ID: <6cc6fb5c-b453-4ad6-b01c-820cc9b78a5b@default>

Looks fine

-----Original Message-----
From: Phil Race 
Sent: Monday, July 2, 2018 10:46 PM
To: Sergey Bylokhov <sergey.bylokhov at oracle.com>; awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>
Subject: Re: [OpenJDK 2D-Dev] <AWT Dev> [11] Review Request: 8201611 Broken links in java.desktop javadoc


OK, +1

-phil.

On 07/02/2018 10:09 AM, Sergey Bylokhov wrote:
> On 02/07/2018 09:29, Phil Race wrote:
>> Not exactly, it was after javadoc was changed under
>> https://bugs.openjdk.java.net/browse/JDK-8195795
>
> So modules are added to the path.
>
>> This one seems to be different than the other two .. no mention of 
>> the module 
>> http://cr.openjdk.java.net/~serb/8201611/webrev.00/src/java.desktop/s
>> hare/classes/javax/imageio/metadata/IIOMetadataNode.java.udiff.html
>
>
> The html tag <a> was replaced by the direct javadoc link to the java 
> class.
>
>> Why is it correct ?
>>
>> -phil.
>>
>>
>> On 07/02/2018 09:11 AM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for jdk11.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201611
>>> Webrev: http://cr.openjdk.java.net/~serb/8201611/webrev.00
>>>
>>> Some links in the javadoc became broken after modules were added.
>>>
>>
>
>


From dipak.kumar at oracle.com  Tue Jul  3 08:40:00 2018
From: dipak.kumar at oracle.com (Dipak Kumar)
Date: Tue, 3 Jul 2018 01:40:00 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] <i18n dev> [8u-backport] Review Request:
 8202696 Remove exclusion range for phonetic chars in windows
 fontconfig.properties
In-Reply-To: <70d9b877-9ce4-4965-89cc-72703071cbb5@default>
References: <70d9b877-9ce4-4965-89cc-72703071cbb5@default>
Message-ID: <35dae94e-939e-497a-aaa3-85a4f9b8a645@default>

Just a gentle reminder. Requesting to review the changes for 8u-backport.

Thanks,
Dipak

-----Original Message-----
From: Dipak Kumar 
Sent: 28 June 2018 14:43
To: 2d-dev at openjdk.java.net; i18n-dev at openjdk.java.net; Philip Race <philip.race at oracle.com>; Naoto Sato <naoto.sato at oracle.com>
Subject: <i18n dev> [8u-backport] Review Request: 8202696 Remove exclusion range for phonetic chars in windows fontconfig.properties

Hi,

Please review below patch for 8u-backport:

Main JBS bug: https://bugs.openjdk.java.net/browse/JDK-8202696 
Webrev for 8u-backport: http://cr.openjdk.java.net/~dkumar/8202696/8u-backport/webrev.00/ 
JDK-11 changeset - http://hg.openjdk.java.net/jdk/client/rev/b9456394d24f 

Patch from JDK-11 doesn't apply cleanly because of file name and file path differences.
Moreover there are some additional ranges added to font exclusion in JDK-11 config file.

JPRT and font related Jtreg tests are fine.

Thanks,
Dipak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20180703/0de1a383/attachment-0001.html>

From naoto.sato at oracle.com  Thu Jul  5 15:48:24 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 5 Jul 2018 08:48:24 -0700
Subject: [OpenJDK 2D-Dev] <i18n dev> [8u-backport] Review Request:
 8202696 Remove exclusion range for phonetic chars in windows
 fontconfig.properties
In-Reply-To: <35dae94e-939e-497a-aaa3-85a4f9b8a645@default>
References: <70d9b877-9ce4-4965-89cc-72703071cbb5@default>
 <35dae94e-939e-497a-aaa3-85a4f9b8a645@default>
Message-ID: <51f6b779-2cb7-ed37-c417-3ddd4190184b@oracle.com>

Looks good to me.

Naoto

On 7/3/18 1:40 AM, Dipak Kumar wrote:
> Just a gentle reminder. Requesting to review the changes for 8u-backport.
> 
> Thanks,
> 
> Dipak
> 
> -----Original Message-----
> From:Dipak Kumar
> Sent:28 June 2018 14:43
> To:2d-dev at openjdk.java.net; i18n-dev at openjdk.java.net; Philip Race 
> <philip.race at oracle.com>; Naoto Sato <naoto.sato at oracle.com>
> Subject:<i18n dev> [8u-backport] Review Request: 8202696 Remove 
> exclusion range for phonetic chars in windows fontconfig.properties
> 
> Hi,
> 
> Please review below patch for 8u-backport:
> 
> Main JBS bug:_https://bugs.openjdk.java.net/browse/JDK-8202696_
> 
> Webrev for 
> 8u-backport:_http://cr.openjdk.java.net/~dkumar/8202696/8u-backport/webrev.00/_
> 
> JDK-11 changeset 
> -_http://hg.openjdk.java.net/jdk/client/rev/b9456394d24f_<http://hg.openjdk.java.net/jdk/client/rev/b9456394d24f>
> 
> Patch from JDK-11 doesn't apply cleanly because of file name and file 
> path differences.
> 
> Moreover there are some additional ranges added to font exclusion in 
> JDK-11 config file.
> 
> JPRT and font related Jtreg tests are fine.
> 
> Thanks,
> 
> Dipak
> 

From philip.race at oracle.com  Thu Jul  5 19:00:26 2018
From: philip.race at oracle.com (Phil Race)
Date: Thu, 5 Jul 2018 12:00:26 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8206428: Upgrade JDK11 to harfbuzz 1.8.2
Message-ID: <aee0dd58-0e36-0137-03e8-70bd297d6748@oracle.com>

bug : https://bugs.openjdk.java.net/browse/JDK-8206428
webrev: http://cr.openjdk.java.net/~prr/8206428/

We need to pick up some important fixes in 1.8.2, so one more upgrade 
for JDK 11.

The diff is relatively small since we are already at 1.8.1

Builds+tests pass.

-phil.

From philip.race at oracle.com  Thu Jul  5 21:06:38 2018
From: philip.race at oracle.com (Phil Race)
Date: Thu, 5 Jul 2018 14:06:38 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8206106: [solaris sparc] jck tests
 api/javax_print/PrintService failing
Message-ID: <72d87434-d87e-86bf-1864-c3d948452506@oracle.com>

bug: https://bugs.openjdk.java.net/browse/JDK-8206106

Current CUPS include files are defining __attribute__ to be empty
We need to undo that to build. Details in the bug report.
built + tested on Solaris, Linux, Mac.

fix :
hg diff src/java.desktop/unix/native/common/awt/CUPSfuncs.c
diff --git a/src/java.desktop/unix/native/common/awt/CUPSfuncs.c 
b/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
--- a/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
+++ b/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
@@ -29,6 +29,12 @@
  #include <dlfcn.h>
  #include <cups/cups.h>
  #include <cups/ppd.h>
+/*
+ * CUPS #define's __attribute__(x) to be empty unless the compiler is 
GNU C.
+ * We need to #undef this else it breaks use of this keyword used by 
JNIEXPORT.
+ */
+#undef __attribute__
+

-phil.

From erik.joelsson at oracle.com  Thu Jul  5 21:09:16 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 5 Jul 2018 14:09:16 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8206106: [solaris sparc] jck tests
 api/javax_print/PrintService failing
In-Reply-To: <72d87434-d87e-86bf-1864-c3d948452506@oracle.com>
References: <72d87434-d87e-86bf-1864-c3d948452506@oracle.com>
Message-ID: <6555520e-c6cc-492b-7b63-4e40c6c94545@oracle.com>

Looks good to me.

I would have thought __attribute__ was a macro originally, but since 
it's not, this looks like a very simple solution. Would be nice if 
Volker could verify this as well.

/Erik


On 2018-07-05 14:06, Phil Race wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8206106
>
> Current CUPS include files are defining __attribute__ to be empty
> We need to undo that to build. Details in the bug report.
> built + tested on Solaris, Linux, Mac.
>
> fix :
> hg diff src/java.desktop/unix/native/common/awt/CUPSfuncs.c
> diff --git a/src/java.desktop/unix/native/common/awt/CUPSfuncs.c 
> b/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
> --- a/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
> +++ b/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
> @@ -29,6 +29,12 @@
> ?#include <dlfcn.h>
> ?#include <cups/cups.h>
> ?#include <cups/ppd.h>
> +/*
> + * CUPS #define's __attribute__(x) to be empty unless the compiler is 
> GNU C.
> + * We need to #undef this else it breaks use of this keyword used by 
> JNIEXPORT.
> + */
> +#undef __attribute__
> +
>
> -phil.


From philip.race at oracle.com  Thu Jul  5 22:13:00 2018
From: philip.race at oracle.com (Phil Race)
Date: Thu, 5 Jul 2018 15:13:00 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> [11] Review Request: 8201611 Broken
 links in java.desktop javadoc
In-Reply-To: <869f7602-d9dd-b266-e392-f06456036e6b@oracle.com>
References: <6db4c190-c358-4f7e-a52d-2205a389f7d7@oracle.com>
 <a62a868b-6f4e-6de3-d786-984c24712ad6@oracle.com>
 <e9d74231-cee5-c20c-7745-15efb2d40bba@oracle.com>
 <869f7602-d9dd-b266-e392-f06456036e6b@oracle.com>
Message-ID: <791bdba3-0b94-1dff-1955-93dd2298af55@oracle.com>

Actually .. I've found that Component.java uses a relative link for 
doc-files in all other cases.
I think that you should actually just remove the usage of @docRoot to 
make it consistent.
It is more logical for this case.

-phil.

On 07/02/2018 10:16 AM, Phil Race wrote:
>
> OK, +1
>
> -phil.
>
> On 07/02/2018 10:09 AM, Sergey Bylokhov wrote:
>> On 02/07/2018 09:29, Phil Race wrote:
>>> Not exactly, it was after javadoc was changed under
>>> https://bugs.openjdk.java.net/browse/JDK-8195795
>>
>> So modules are added to the path.
>>
>>> This one seems to be different than the other two .. no mention of 
>>> the module
>>> http://cr.openjdk.java.net/~serb/8201611/webrev.00/src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadataNode.java.udiff.html 
>>
>>
>>
>> The html tag <a> was replaced by the direct javadoc link to the java 
>> class.
>>
>>> Why is it correct ?
>>>
>>> -phil.
>>>
>>>
>>> On 07/02/2018 09:11 AM, Sergey Bylokhov wrote:
>>>> Hello.
>>>> Please review the fix for jdk11.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201611
>>>> Webrev: http://cr.openjdk.java.net/~serb/8201611/webrev.00
>>>>
>>>> Some links in the javadoc became broken after modules were added.
>>>>
>>>
>>
>>
>


From volker.simonis at gmail.com  Fri Jul  6 08:24:39 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 6 Jul 2018 10:24:39 +0200
Subject: [OpenJDK 2D-Dev] RFR: 8206106: [solaris sparc] jck tests
 api/javax_print/PrintService failing
In-Reply-To: <6555520e-c6cc-492b-7b63-4e40c6c94545@oracle.com>
References: <72d87434-d87e-86bf-1864-c3d948452506@oracle.com>
 <6555520e-c6cc-492b-7b63-4e40c6c94545@oracle.com>
Message-ID: <CA+3eh103uHoq4TQfSv+wgaVu+Od0L24i4pWpx6ZeTX0y7E7Zuw@mail.gmail.com>

Hi Phil,

I've actually thought about the same trick yesterday in the evening
and just wanted to try it out when I saw your mail. It indeed works
quite nicely and I can confirm that it solves the problem on our side
as well. I've also opened an issue in the CUPS bug tracker:
https://github.com/apple/cups/issues/5349

I'f you don't mind, I'd suggest to wrap this workaround into "#ifdef
__solaris__" to not affect any other platforms at all. I also suggest
to slightly change the comment to "unless __GNUC__ is defined" because
there are compilers like Clang which are not GNU C but define
"__GNUC__". Finally, I'd also put a link to the CUPS issue into the
comment:

diff -r 93043d28f8fa src/java.desktop/unix/native/common/awt/CUPSfuncs.c
--- a/src/java.desktop/unix/native/common/awt/CUPSfuncs.c       Tue
Jun 12 13:00:50 2018 +0530
+++ b/src/java.desktop/unix/native/common/awt/CUPSfuncs.c       Fri
Jul 06 10:17:39 2018 +0200
@@ -30,6 +30,15 @@
 #include <cups/cups.h>
 #include <cups/ppd.h>

+#ifdef __solaris__
+  /*
+   * CUPS #define's __attribute__(x) to be empty unless __GNUC__ is defined.
+   * We need to #undef this else it breaks use of this keyword used
by JNIEXPORT.
+   * See: https://github.com/apple/cups/issues/5349
+   */
+  #undef __attribute__
+#endif
+
 //#define CUPS_DEBUG

 #ifdef CUPS_DEBUG

Thank you and best regards,
Volker


On Thu, Jul 5, 2018 at 11:09 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> Looks good to me.
>
> I would have thought __attribute__ was a macro originally, but since it's
> not, this looks like a very simple solution. Would be nice if Volker could
> verify this as well.
>
> /Erik
>
>
>
> On 2018-07-05 14:06, Phil Race wrote:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8206106
>>
>> Current CUPS include files are defining __attribute__ to be empty
>> We need to undo that to build. Details in the bug report.
>> built + tested on Solaris, Linux, Mac.
>>
>> fix :
>> hg diff src/java.desktop/unix/native/common/awt/CUPSfuncs.c
>> diff --git a/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
>> b/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
>> --- a/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
>> +++ b/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
>> @@ -29,6 +29,12 @@
>>  #include <dlfcn.h>
>>  #include <cups/cups.h>
>>  #include <cups/ppd.h>
>> +/*
>> + * CUPS #define's __attribute__(x) to be empty unless the compiler is GNU
>> C.
>> + * We need to #undef this else it breaks use of this keyword used by
>> JNIEXPORT.
>> + */
>> +#undef __attribute__
>> +
>>
>> -phil.
>
>

From Sergey.Bylokhov at oracle.com  Fri Jul  6 15:00:56 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 6 Jul 2018 18:00:56 +0300
Subject: [OpenJDK 2D-Dev] <AWT Dev> [11] Review Request: 8201611 Broken
 links in java.desktop javadoc
In-Reply-To: <791bdba3-0b94-1dff-1955-93dd2298af55@oracle.com>
References: <6db4c190-c358-4f7e-a52d-2205a389f7d7@oracle.com>
 <a62a868b-6f4e-6de3-d786-984c24712ad6@oracle.com>
 <e9d74231-cee5-c20c-7745-15efb2d40bba@oracle.com>
 <869f7602-d9dd-b266-e392-f06456036e6b@oracle.com>
 <791bdba3-0b94-1dff-1955-93dd2298af55@oracle.com>
Message-ID: <5b2933c2-2b28-cbc9-31db-83374123062e@oracle.com>

On 06/07/2018 01:13, Phil Race wrote:
> Actually .. I've found that Component.java uses a relative link for 
> doc-files in all other cases.
> I think that you should actually just remove the usage of @docRoot to 
> make it consistent.
> It is more logical for this case.

In this method the "@docRoot" cannot be removed(it was added there 
intentionally), because this method is overridden by some of our classes 
where the relative link does not work.

> 
> -phil.
> 
> On 07/02/2018 10:16 AM, Phil Race wrote:
>>
>> OK, +1
>>
>> -phil.
>>
>> On 07/02/2018 10:09 AM, Sergey Bylokhov wrote:
>>> On 02/07/2018 09:29, Phil Race wrote:
>>>> Not exactly, it was after javadoc was changed under
>>>> https://bugs.openjdk.java.net/browse/JDK-8195795
>>>
>>> So modules are added to the path.
>>>
>>>> This one seems to be different than the other two .. no mention of 
>>>> the module
>>>> http://cr.openjdk.java.net/~serb/8201611/webrev.00/src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadataNode.java.udiff.html 
>>>
>>>
>>>
>>>
>>> The html tag <a> was replaced by the direct javadoc link to the java 
>>> class.
>>>
>>>> Why is it correct ?
>>>>
>>>> -phil.
>>>>
>>>>
>>>> On 07/02/2018 09:11 AM, Sergey Bylokhov wrote:
>>>>> Hello.
>>>>> Please review the fix for jdk11.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201611
>>>>> Webrev: http://cr.openjdk.java.net/~serb/8201611/webrev.00
>>>>>
>>>>> Some links in the javadoc became broken after modules were added.
>>>>>
>>>>
>>>
>>>
>>
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Fri Jul  6 15:27:35 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 6 Jul 2018 18:27:35 +0300
Subject: [OpenJDK 2D-Dev] RFR: 8206428: Upgrade JDK11 to harfbuzz 1.8.2
In-Reply-To: <aee0dd58-0e36-0137-03e8-70bd297d6748@oracle.com>
References: <aee0dd58-0e36-0137-03e8-70bd297d6748@oracle.com>
Message-ID: <586847ae-475b-9e4e-8137-5cc671213030@oracle.com>

Looks fine.

On 05/07/2018 22:00, Phil Race wrote:
> bug : https://bugs.openjdk.java.net/browse/JDK-8206428
> webrev: http://cr.openjdk.java.net/~prr/8206428/
> 
> We need to pick up some important fixes in 1.8.2, so one more upgrade 
> for JDK 11.
> 
> The diff is relatively small since we are already at 1.8.1
> 
> Builds+tests pass.
> 
> -phil.


-- 
Best regards, Sergey.

From philip.race at oracle.com  Fri Jul  6 15:28:26 2018
From: philip.race at oracle.com (Phil Race)
Date: Fri, 6 Jul 2018 08:28:26 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> [11] Review Request: 8201611 Broken
	links in java.desktop javadoc
In-Reply-To: <5b2933c2-2b28-cbc9-31db-83374123062e@oracle.com>
References: <6db4c190-c358-4f7e-a52d-2205a389f7d7@oracle.com>
 <a62a868b-6f4e-6de3-d786-984c24712ad6@oracle.com>
 <e9d74231-cee5-c20c-7745-15efb2d40bba@oracle.com>
 <869f7602-d9dd-b266-e392-f06456036e6b@oracle.com>
 <791bdba3-0b94-1dff-1955-93dd2298af55@oracle.com>
 <5b2933c2-2b28-cbc9-31db-83374123062e@oracle.com>
Message-ID: <8535476D-33AD-497F-A819-B58AB06B40B7@oracle.com>

Oh. Ok. Tricky!

-Phil.

> On Jul 6, 2018, at 8:00 AM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
>> On 06/07/2018 01:13, Phil Race wrote:
>> Actually .. I've found that Component.java uses a relative link for doc-files in all other cases.
>> I think that you should actually just remove the usage of @docRoot to make it consistent.
>> It is more logical for this case.
> 
> In this method the "@docRoot" cannot be removed(it was added there intentionally), because this method is overridden by some of our classes where the relative link does not work.
> 
>> -phil.
>>> On 07/02/2018 10:16 AM, Phil Race wrote:
>>> 
>>> OK, +1
>>> 
>>> -phil.
>>> 
>>>> On 07/02/2018 10:09 AM, Sergey Bylokhov wrote:
>>>>> On 02/07/2018 09:29, Phil Race wrote:
>>>>> Not exactly, it was after javadoc was changed under
>>>>> https://bugs.openjdk.java.net/browse/JDK-8195795
>>>> 
>>>> So modules are added to the path.
>>>> 
>>>>> This one seems to be different than the other two .. no mention of the module
>>>>> http://cr.openjdk.java.net/~serb/8201611/webrev.00/src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadataNode.java.udiff.html 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> The html tag <a> was replaced by the direct javadoc link to the java class.
>>>> 
>>>>> Why is it correct ?
>>>>> 
>>>>> -phil.
>>>>> 
>>>>> 
>>>>>> On 07/02/2018 09:11 AM, Sergey Bylokhov wrote:
>>>>>> Hello.
>>>>>> Please review the fix for jdk11.
>>>>>> 
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201611
>>>>>> Webrev: http://cr.openjdk.java.net/~serb/8201611/webrev.00
>>>>>> 
>>>>>> Some links in the javadoc became broken after modules were added.
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
> 
> 
> -- 
> Best regards, Sergey.


From philip.race at oracle.com  Fri Jul  6 16:29:42 2018
From: philip.race at oracle.com (Phil Race)
Date: Fri, 6 Jul 2018 09:29:42 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8206106: [solaris sparc] jck tests
 api/javax_print/PrintService failing
In-Reply-To: <CA+3eh103uHoq4TQfSv+wgaVu+Od0L24i4pWpx6ZeTX0y7E7Zuw@mail.gmail.com>
References: <72d87434-d87e-86bf-1864-c3d948452506@oracle.com>
 <6555520e-c6cc-492b-7b63-4e40c6c94545@oracle.com>
 <CA+3eh103uHoq4TQfSv+wgaVu+Od0L24i4pWpx6ZeTX0y7E7Zuw@mail.gmail.com>
Message-ID: <54cfaddf-cc51-7927-f339-e753f5cce7fb@oracle.com>

I was trying to account for there being other OSes - or more accurately, 
compilers,
that would be broken by this. For example Oracle Studio has a Linux 
version !

If we are to limit it, I suggest that we do

#ifdef __SUNPRO_C
...

https://docs.oracle.com/cd/E19205-01/820-4155/c++_faq.html#Vers6

-phil.

On 07/06/2018 01:24 AM, Volker Simonis wrote:
> Hi Phil,
>
> I've actually thought about the same trick yesterday in the evening
> and just wanted to try it out when I saw your mail. It indeed works
> quite nicely and I can confirm that it solves the problem on our side
> as well. I've also opened an issue in the CUPS bug tracker:
> https://github.com/apple/cups/issues/5349
>
> I'f you don't mind, I'd suggest to wrap this workaround into "#ifdef
> __solaris__" to not affect any other platforms at all. I also suggest
> to slightly change the comment to "unless __GNUC__ is defined" because
> there are compilers like Clang which are not GNU C but define
> "__GNUC__". Finally, I'd also put a link to the CUPS issue into the
> comment:
>
> diff -r 93043d28f8fa src/java.desktop/unix/native/common/awt/CUPSfuncs.c
> --- a/src/java.desktop/unix/native/common/awt/CUPSfuncs.c       Tue
> Jun 12 13:00:50 2018 +0530
> +++ b/src/java.desktop/unix/native/common/awt/CUPSfuncs.c       Fri
> Jul 06 10:17:39 2018 +0200
> @@ -30,6 +30,15 @@
>   #include <cups/cups.h>
>   #include <cups/ppd.h>
>
> +#ifdef __solaris__
> +  /*
> +   * CUPS #define's __attribute__(x) to be empty unless __GNUC__ is defined.
> +   * We need to #undef this else it breaks use of this keyword used
> by JNIEXPORT.
> +   * See: https://github.com/apple/cups/issues/5349
> +   */
> +  #undef __attribute__
> +#endif
> +
>   //#define CUPS_DEBUG
>
>   #ifdef CUPS_DEBUG
>
> Thank you and best regards,
> Volker
>
>
> On Thu, Jul 5, 2018 at 11:09 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>> Looks good to me.
>>
>> I would have thought __attribute__ was a macro originally, but since it's
>> not, this looks like a very simple solution. Would be nice if Volker could
>> verify this as well.
>>
>> /Erik
>>
>>
>>
>> On 2018-07-05 14:06, Phil Race wrote:
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8206106
>>>
>>> Current CUPS include files are defining __attribute__ to be empty
>>> We need to undo that to build. Details in the bug report.
>>> built + tested on Solaris, Linux, Mac.
>>>
>>> fix :
>>> hg diff src/java.desktop/unix/native/common/awt/CUPSfuncs.c
>>> diff --git a/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
>>> b/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
>>> --- a/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
>>> +++ b/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
>>> @@ -29,6 +29,12 @@
>>>   #include <dlfcn.h>
>>>   #include <cups/cups.h>
>>>   #include <cups/ppd.h>
>>> +/*
>>> + * CUPS #define's __attribute__(x) to be empty unless the compiler is GNU
>>> C.
>>> + * We need to #undef this else it breaks use of this keyword used by
>>> JNIEXPORT.
>>> + */
>>> +#undef __attribute__
>>> +
>>>
>>> -phil.
>>


From philip.race at oracle.com  Fri Jul  6 17:06:28 2018
From: philip.race at oracle.com (Phil Race)
Date: Fri, 6 Jul 2018 10:06:28 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8206106: [solaris sparc] jck tests
 api/javax_print/PrintService failing
In-Reply-To: <54cfaddf-cc51-7927-f339-e753f5cce7fb@oracle.com>
References: <72d87434-d87e-86bf-1864-c3d948452506@oracle.com>
 <6555520e-c6cc-492b-7b63-4e40c6c94545@oracle.com>
 <CA+3eh103uHoq4TQfSv+wgaVu+Od0L24i4pWpx6ZeTX0y7E7Zuw@mail.gmail.com>
 <54cfaddf-cc51-7927-f339-e753f5cce7fb@oracle.com>
Message-ID: <e0697ee8-8c31-51cc-7b53-665a0a0cebb8@oracle.com>

Updated suggested fix :

--- a/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
+++ b/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
@@ -29,6 +29,16 @@
  #include <dlfcn.h>
  #include <cups/cups.h>
  #include <cups/ppd.h>
+/*
+ * CUPS #define's __attribute__(x) to be empty unless __GNUC__ is defined.
+ * However OpenJDK officially uses the SunStudio compiler on Solaris.
+ * We need to #undef this else it breaks use of this keyword used by 
JNIEXPORT.
+ * See: https://github.com/apple/cups/issues/5349
+ */
+#ifdef __SUNPRO_C
+#undef __attribute__
+#endif
+


Since cups upstream has this issue even today, I suspect this workaround 
is going to be
needed for a long time.

-phil.

On 07/06/2018 09:29 AM, Phil Race wrote:
> I was trying to account for there being other OSes - or more 
> accurately, compilers,
> that would be broken by this. For example Oracle Studio has a Linux 
> version !
>
> If we are to limit it, I suggest that we do
>
> #ifdef __SUNPRO_C
> ...
>
> https://docs.oracle.com/cd/E19205-01/820-4155/c++_faq.html#Vers6
>
> -phil.
>
> On 07/06/2018 01:24 AM, Volker Simonis wrote:
>> Hi Phil,
>>
>> I've actually thought about the same trick yesterday in the evening
>> and just wanted to try it out when I saw your mail. It indeed works
>> quite nicely and I can confirm that it solves the problem on our side
>> as well. I've also opened an issue in the CUPS bug tracker:
>> https://github.com/apple/cups/issues/5349
>>
>> I'f you don't mind, I'd suggest to wrap this workaround into "#ifdef
>> __solaris__" to not affect any other platforms at all. I also suggest
>> to slightly change the comment to "unless __GNUC__ is defined" because
>> there are compilers like Clang which are not GNU C but define
>> "__GNUC__". Finally, I'd also put a link to the CUPS issue into the
>> comment:
>>
>> diff -r 93043d28f8fa src/java.desktop/unix/native/common/awt/CUPSfuncs.c
>> --- a/src/java.desktop/unix/native/common/awt/CUPSfuncs.c Tue
>> Jun 12 13:00:50 2018 +0530
>> +++ b/src/java.desktop/unix/native/common/awt/CUPSfuncs.c Fri
>> Jul 06 10:17:39 2018 +0200
>> @@ -30,6 +30,15 @@
>>   #include <cups/cups.h>
>>   #include <cups/ppd.h>
>>
>> +#ifdef __solaris__
>> +  /*
>> +   * CUPS #define's __attribute__(x) to be empty unless __GNUC__ is 
>> defined.
>> +   * We need to #undef this else it breaks use of this keyword used
>> by JNIEXPORT.
>> +   * See: https://github.com/apple/cups/issues/5349
>> +   */
>> +  #undef __attribute__
>> +#endif
>> +
>>   //#define CUPS_DEBUG
>>
>>   #ifdef CUPS_DEBUG
>>
>> Thank you and best regards,
>> Volker
>>
>>
>> On Thu, Jul 5, 2018 at 11:09 PM, Erik Joelsson 
>> <erik.joelsson at oracle.com> wrote:
>>> Looks good to me.
>>>
>>> I would have thought __attribute__ was a macro originally, but since 
>>> it's
>>> not, this looks like a very simple solution. Would be nice if Volker 
>>> could
>>> verify this as well.
>>>
>>> /Erik
>>>
>>>
>>>
>>> On 2018-07-05 14:06, Phil Race wrote:
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8206106
>>>>
>>>> Current CUPS include files are defining __attribute__ to be empty
>>>> We need to undo that to build. Details in the bug report.
>>>> built + tested on Solaris, Linux, Mac.
>>>>
>>>> fix :
>>>> hg diff src/java.desktop/unix/native/common/awt/CUPSfuncs.c
>>>> diff --git a/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
>>>> b/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
>>>> --- a/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
>>>> +++ b/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
>>>> @@ -29,6 +29,12 @@
>>>>   #include <dlfcn.h>
>>>>   #include <cups/cups.h>
>>>>   #include <cups/ppd.h>
>>>> +/*
>>>> + * CUPS #define's __attribute__(x) to be empty unless the compiler 
>>>> is GNU
>>>> C.
>>>> + * We need to #undef this else it breaks use of this keyword used by
>>>> JNIEXPORT.
>>>> + */
>>>> +#undef __attribute__
>>>> +
>>>>
>>>> -phil.
>>>
>


From erik.joelsson at oracle.com  Fri Jul  6 17:11:58 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 6 Jul 2018 10:11:58 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8206106: [solaris sparc] jck tests
 api/javax_print/PrintService failing
In-Reply-To: <e0697ee8-8c31-51cc-7b53-665a0a0cebb8@oracle.com>
References: <72d87434-d87e-86bf-1864-c3d948452506@oracle.com>
 <6555520e-c6cc-492b-7b63-4e40c6c94545@oracle.com>
 <CA+3eh103uHoq4TQfSv+wgaVu+Od0L24i4pWpx6ZeTX0y7E7Zuw@mail.gmail.com>
 <54cfaddf-cc51-7927-f339-e753f5cce7fb@oracle.com>
 <e0697ee8-8c31-51cc-7b53-665a0a0cebb8@oracle.com>
Message-ID: <d65cbc2c-5b07-32c0-38d2-ccc5a9eb4255@oracle.com>

This looks even better.

/Erik


On 2018-07-06 10:06, Phil Race wrote:
> Updated suggested fix :
>
> --- a/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
> +++ b/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
> @@ -29,6 +29,16 @@
> ?#include <dlfcn.h>
> ?#include <cups/cups.h>
> ?#include <cups/ppd.h>
> +/*
> + * CUPS #define's __attribute__(x) to be empty unless __GNUC__ is 
> defined.
> + * However OpenJDK officially uses the SunStudio compiler on Solaris.
> + * We need to #undef this else it breaks use of this keyword used by 
> JNIEXPORT.
> + * See: https://github.com/apple/cups/issues/5349
> + */
> +#ifdef __SUNPRO_C
> +#undef __attribute__
> +#endif
> +
>
>
> Since cups upstream has this issue even today, I suspect this 
> workaround is going to be
> needed for a long time.
>
> -phil.
>
> On 07/06/2018 09:29 AM, Phil Race wrote:
>> I was trying to account for there being other OSes - or more 
>> accurately, compilers,
>> that would be broken by this. For example Oracle Studio has a Linux 
>> version !
>>
>> If we are to limit it, I suggest that we do
>>
>> #ifdef __SUNPRO_C
>> ...
>>
>> https://docs.oracle.com/cd/E19205-01/820-4155/c++_faq.html#Vers6
>>
>> -phil.
>>
>> On 07/06/2018 01:24 AM, Volker Simonis wrote:
>>> Hi Phil,
>>>
>>> I've actually thought about the same trick yesterday in the evening
>>> and just wanted to try it out when I saw your mail. It indeed works
>>> quite nicely and I can confirm that it solves the problem on our side
>>> as well. I've also opened an issue in the CUPS bug tracker:
>>> https://github.com/apple/cups/issues/5349
>>>
>>> I'f you don't mind, I'd suggest to wrap this workaround into "#ifdef
>>> __solaris__" to not affect any other platforms at all. I also suggest
>>> to slightly change the comment to "unless __GNUC__ is defined" because
>>> there are compilers like Clang which are not GNU C but define
>>> "__GNUC__". Finally, I'd also put a link to the CUPS issue into the
>>> comment:
>>>
>>> diff -r 93043d28f8fa 
>>> src/java.desktop/unix/native/common/awt/CUPSfuncs.c
>>> --- a/src/java.desktop/unix/native/common/awt/CUPSfuncs.c Tue
>>> Jun 12 13:00:50 2018 +0530
>>> +++ b/src/java.desktop/unix/native/common/awt/CUPSfuncs.c Fri
>>> Jul 06 10:17:39 2018 +0200
>>> @@ -30,6 +30,15 @@
>>> ? #include <cups/cups.h>
>>> ? #include <cups/ppd.h>
>>>
>>> +#ifdef __solaris__
>>> +? /*
>>> +?? * CUPS #define's __attribute__(x) to be empty unless __GNUC__ is 
>>> defined.
>>> +?? * We need to #undef this else it breaks use of this keyword used
>>> by JNIEXPORT.
>>> +?? * See: https://github.com/apple/cups/issues/5349
>>> +?? */
>>> +? #undef __attribute__
>>> +#endif
>>> +
>>> ? //#define CUPS_DEBUG
>>>
>>> ? #ifdef CUPS_DEBUG
>>>
>>> Thank you and best regards,
>>> Volker
>>>
>>>
>>> On Thu, Jul 5, 2018 at 11:09 PM, Erik Joelsson 
>>> <erik.joelsson at oracle.com> wrote:
>>>> Looks good to me.
>>>>
>>>> I would have thought __attribute__ was a macro originally, but 
>>>> since it's
>>>> not, this looks like a very simple solution. Would be nice if 
>>>> Volker could
>>>> verify this as well.
>>>>
>>>> /Erik
>>>>
>>>>
>>>>
>>>> On 2018-07-05 14:06, Phil Race wrote:
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8206106
>>>>>
>>>>> Current CUPS include files are defining __attribute__ to be empty
>>>>> We need to undo that to build. Details in the bug report.
>>>>> built + tested on Solaris, Linux, Mac.
>>>>>
>>>>> fix :
>>>>> hg diff src/java.desktop/unix/native/common/awt/CUPSfuncs.c
>>>>> diff --git a/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
>>>>> b/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
>>>>> --- a/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
>>>>> +++ b/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
>>>>> @@ -29,6 +29,12 @@
>>>>> ? #include <dlfcn.h>
>>>>> ? #include <cups/cups.h>
>>>>> ? #include <cups/ppd.h>
>>>>> +/*
>>>>> + * CUPS #define's __attribute__(x) to be empty unless the 
>>>>> compiler is GNU
>>>>> C.
>>>>> + * We need to #undef this else it breaks use of this keyword used by
>>>>> JNIEXPORT.
>>>>> + */
>>>>> +#undef __attribute__
>>>>> +
>>>>>
>>>>> -phil.
>>>>
>>
>


From gersimon at outlook.de  Sat Jul  7 00:13:12 2018
From: gersimon at outlook.de (Simon Ge)
Date: Sat, 7 Jul 2018 00:13:12 +0000
Subject: [OpenJDK 2D-Dev] Java2D - Fast(er) Image scaling using
	AreaAveragingScaleFilter
Message-ID: <AM3PR08MB072224E93C13D9E6ADC2061CC8460@AM3PR08MB0722.eurprd08.prod.outlook.com>

Hello,
My name is Simon Gerst. I am a student from Germany and "working" on image scaling.


As an assignment I have to optimize an image manipulation function for speed it does some scaling and image copying.
I am using BufferedImage.getScaledInstance(w, h, SCALE_AREA_AVERAGING) for scaling.
Profiling has shown me that the above call seems to be a bottleneck.

Looking at the source, the above call internally uses an AreaAveragingScaleFilter.
I'd be very glad if you could maybe answer me two questions:

1) Is there some kind of blog post or documentation on how the AreaAveragingScaleFilter works?
I've read the Javadoc but did not yet understand how it precisely works.

2) Are there any "obvious" performance improvements possible in the case where the input image is a BufferedImage?
I think that there might be a faster method since BufferedImage could ignore the ImageProducer stuff.


I've found this [0] blog post which suggests using another way of scaling which I unfortunately can not do.

This is my first mail to this list and I hope this is the right place for my question.


~Simon

[0] http://web.archive.org/web/20070414170207/https://today.java.net/pub/a/today/2007/04/03/perils-of-image-getscaledinstance.html

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

From brian.burkhalter at oracle.com  Sat Jul  7 00:20:28 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 6 Jul 2018 17:20:28 -0700
Subject: [OpenJDK 2D-Dev] Java2D - Fast(er) Image scaling using
	AreaAveragingScaleFilter
In-Reply-To: <AM3PR08MB072224E93C13D9E6ADC2061CC8460@AM3PR08MB0722.eurprd08.prod.outlook.com>
References: <AM3PR08MB072224E93C13D9E6ADC2061CC8460@AM3PR08MB0722.eurprd08.prod.outlook.com>
Message-ID: <9F099458-BEB6-4904-AE27-34D80C38F74D@oracle.com>

Hello,

I do not know for certain but I suspect that it is similar to this:

https://docs.oracle.com/cd/E17802_01/products/products/java-media/jai/forDevelopers/jai-apidocs/javax/media/jai/operator/SubsampleAverageDescriptor.html

Brian

On Jul 6, 2018, at 5:13 PM, Simon Ge <gersimon at outlook.de> wrote:

> 1) Is there some kind of blog post or documentation on how the AreaAveragingScaleFilter works?
> I've read the Javadoc but did not yet understand how it precisely works.

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

From volker.simonis at gmail.com  Mon Jul  9 12:29:06 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 9 Jul 2018 14:29:06 +0200
Subject: [OpenJDK 2D-Dev] RFR: 8206106: [solaris sparc] jck tests
 api/javax_print/PrintService failing
In-Reply-To: <e0697ee8-8c31-51cc-7b53-665a0a0cebb8@oracle.com>
References: <72d87434-d87e-86bf-1864-c3d948452506@oracle.com>
 <6555520e-c6cc-492b-7b63-4e40c6c94545@oracle.com>
 <CA+3eh103uHoq4TQfSv+wgaVu+Od0L24i4pWpx6ZeTX0y7E7Zuw@mail.gmail.com>
 <54cfaddf-cc51-7927-f339-e753f5cce7fb@oracle.com>
 <e0697ee8-8c31-51cc-7b53-665a0a0cebb8@oracle.com>
Message-ID: <CA+3eh134nunTFrvHh5ptbTov1=TOoqdvdL5df09GpS_nL1+_2w@mail.gmail.com>

Looks good!

Thanks,
Volker


On Fri, Jul 6, 2018 at 7:06 PM, Phil Race <philip.race at oracle.com> wrote:
> Updated suggested fix :
>
> --- a/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
> +++ b/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
> @@ -29,6 +29,16 @@
>  #include <dlfcn.h>
>  #include <cups/cups.h>
>  #include <cups/ppd.h>
> +/*
> + * CUPS #define's __attribute__(x) to be empty unless __GNUC__ is defined.
> + * However OpenJDK officially uses the SunStudio compiler on Solaris.
> + * We need to #undef this else it breaks use of this keyword used by
> JNIEXPORT.
> + * See: https://github.com/apple/cups/issues/5349
> + */
> +#ifdef __SUNPRO_C
> +#undef __attribute__
> +#endif
> +
>
>
> Since cups upstream has this issue even today, I suspect this workaround is
> going to be
> needed for a long time.
>
> -phil.
>
>
> On 07/06/2018 09:29 AM, Phil Race wrote:
>>
>> I was trying to account for there being other OSes - or more accurately,
>> compilers,
>> that would be broken by this. For example Oracle Studio has a Linux
>> version !
>>
>> If we are to limit it, I suggest that we do
>>
>> #ifdef __SUNPRO_C
>> ...
>>
>> https://docs.oracle.com/cd/E19205-01/820-4155/c++_faq.html#Vers6
>>
>> -phil.
>>
>> On 07/06/2018 01:24 AM, Volker Simonis wrote:
>>>
>>> Hi Phil,
>>>
>>> I've actually thought about the same trick yesterday in the evening
>>> and just wanted to try it out when I saw your mail. It indeed works
>>> quite nicely and I can confirm that it solves the problem on our side
>>> as well. I've also opened an issue in the CUPS bug tracker:
>>> https://github.com/apple/cups/issues/5349
>>>
>>> I'f you don't mind, I'd suggest to wrap this workaround into "#ifdef
>>> __solaris__" to not affect any other platforms at all. I also suggest
>>> to slightly change the comment to "unless __GNUC__ is defined" because
>>> there are compilers like Clang which are not GNU C but define
>>> "__GNUC__". Finally, I'd also put a link to the CUPS issue into the
>>> comment:
>>>
>>> diff -r 93043d28f8fa src/java.desktop/unix/native/common/awt/CUPSfuncs.c
>>> --- a/src/java.desktop/unix/native/common/awt/CUPSfuncs.c Tue
>>> Jun 12 13:00:50 2018 +0530
>>> +++ b/src/java.desktop/unix/native/common/awt/CUPSfuncs.c Fri
>>> Jul 06 10:17:39 2018 +0200
>>> @@ -30,6 +30,15 @@
>>>   #include <cups/cups.h>
>>>   #include <cups/ppd.h>
>>>
>>> +#ifdef __solaris__
>>> +  /*
>>> +   * CUPS #define's __attribute__(x) to be empty unless __GNUC__ is
>>> defined.
>>> +   * We need to #undef this else it breaks use of this keyword used
>>> by JNIEXPORT.
>>> +   * See: https://github.com/apple/cups/issues/5349
>>> +   */
>>> +  #undef __attribute__
>>> +#endif
>>> +
>>>   //#define CUPS_DEBUG
>>>
>>>   #ifdef CUPS_DEBUG
>>>
>>> Thank you and best regards,
>>> Volker
>>>
>>>
>>> On Thu, Jul 5, 2018 at 11:09 PM, Erik Joelsson <erik.joelsson at oracle.com>
>>> wrote:
>>>>
>>>> Looks good to me.
>>>>
>>>> I would have thought __attribute__ was a macro originally, but since
>>>> it's
>>>> not, this looks like a very simple solution. Would be nice if Volker
>>>> could
>>>> verify this as well.
>>>>
>>>> /Erik
>>>>
>>>>
>>>>
>>>> On 2018-07-05 14:06, Phil Race wrote:
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8206106
>>>>>
>>>>> Current CUPS include files are defining __attribute__ to be empty
>>>>> We need to undo that to build. Details in the bug report.
>>>>> built + tested on Solaris, Linux, Mac.
>>>>>
>>>>> fix :
>>>>> hg diff src/java.desktop/unix/native/common/awt/CUPSfuncs.c
>>>>> diff --git a/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
>>>>> b/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
>>>>> --- a/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
>>>>> +++ b/src/java.desktop/unix/native/common/awt/CUPSfuncs.c
>>>>> @@ -29,6 +29,12 @@
>>>>>   #include <dlfcn.h>
>>>>>   #include <cups/cups.h>
>>>>>   #include <cups/ppd.h>
>>>>> +/*
>>>>> + * CUPS #define's __attribute__(x) to be empty unless the compiler is
>>>>> GNU
>>>>> C.
>>>>> + * We need to #undef this else it breaks use of this keyword used by
>>>>> JNIEXPORT.
>>>>> + */
>>>>> +#undef __attribute__
>>>>> +
>>>>>
>>>>> -phil.
>>>>
>>>>
>>
>

From neugens at redhat.com  Wed Jul 18 11:06:45 2018
From: neugens at redhat.com (Mario Torre)
Date: Wed, 18 Jul 2018 13:06:45 +0200
Subject: [OpenJDK 2D-Dev] Request for re-reviewl: Backport of JDK-8150954:
 Taking screenshots on x11 composite desktop produce wrong result
Message-ID: <CAJwKKmYrgu7Sk=PagC_F=3AMpvRWe=akh4XVbW+nRQ1rkdyyxQ@mail.gmail.com>

Hi all,

I would like to backport the fix for:

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

To OpenJDK8 updates dev:

http://hg.openjdk.java.net/jdk8u/jdk8u-dev

The fix is mostly the same as the version that was committed in 9,
with the exception of the GTK path which is not available in 8.

http://cr.openjdk.java.net/~neugens/8150954/webrev-jdk8u.00/

I'm not sure if this change needs a re-review from the 2d team, as I
think is trivial, but I would like some feedback nonetheless before
proposing to the updates mailing list, especially in regards to
testing the patch on some OS variant without the necessary libraries.

Cheers,
Mario

-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From philip.race at oracle.com  Wed Jul 18 21:28:53 2018
From: philip.race at oracle.com (Phil Race)
Date: Wed, 18 Jul 2018 14:28:53 -0700
Subject: [OpenJDK 2D-Dev] Request for re-reviewl: Backport of
 JDK-8150954: Taking screenshots on x11 composite desktop produce wrong
 result
In-Reply-To: <CAJwKKmYrgu7Sk=PagC_F=3AMpvRWe=akh4XVbW+nRQ1rkdyyxQ@mail.gmail.com>
References: <CAJwKKmYrgu7Sk=PagC_F=3AMpvRWe=akh4XVbW+nRQ1rkdyyxQ@mail.gmail.com>
Message-ID: <3e183051-31b5-f9b6-5622-d6d787d3a0b1@oracle.com>

The review for the original fix was actually on awt-dev which probably 
was correct
and so this should be there too.
I hadn't seen the thread so had to go read it .. but it was so long ago I'd
probably have had to re-read it anyway. But it was not so easy to find
since it did not have the bug ID in the subject !
http://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010742.html
http://mail.openjdk.java.net/pipermail/awt-dev/2016-April/010996.html
http://mail.openjdk.java.net/pipermail/awt-dev/2016-May/011370.html

Since it is changed, yes, being able to point to this review thread is 
likely
something the 8u-dev maintainers would ask you for.

It looks OK to me although I don't grok why the order here in 8u

302 if (isXCompositeDisplay(awt_display, adata->awt_visInfo.screen) &&
303 hasXCompositeOverlayExtension(awt_display))

is reversed from what you had in 9 : 309 if 
(hasXCompositeOverlayExtension(awt_display) &&
310 isXCompositeDisplay(awt_display, adata->awt_visInfo.screen)) which 
looks more logical to me.

-phil.

On 07/18/2018 04:06 AM, Mario Torre wrote:
> Hi all,
>
> I would like to backport the fix for:
>
> https://bugs.openjdk.java.net/browse/JDK-8150954
>
> To OpenJDK8 updates dev:
>
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev
>
> The fix is mostly the same as the version that was committed in 9,
> with the exception of the GTK path which is not available in 8.
>
> http://cr.openjdk.java.net/~neugens/8150954/webrev-jdk8u.00/
>
> I'm not sure if this change needs a re-review from the 2d team, as I
> think is trivial, but I would like some feedback nonetheless before
> proposing to the updates mailing list, especially in regards to
> testing the patch on some OS variant without the necessary libraries.
>
> Cheers,
> Mario
>

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

From neugens at redhat.com  Thu Jul 19 12:33:32 2018
From: neugens at redhat.com (Mario Torre)
Date: Thu, 19 Jul 2018 14:33:32 +0200
Subject: [OpenJDK 2D-Dev] Request for re-reviewl: Backport of
 JDK-8150954: Taking screenshots on x11 composite desktop produce wrong
 result
In-Reply-To: <3e183051-31b5-f9b6-5622-d6d787d3a0b1@oracle.com>
References: <CAJwKKmYrgu7Sk=PagC_F=3AMpvRWe=akh4XVbW+nRQ1rkdyyxQ@mail.gmail.com>
 <3e183051-31b5-f9b6-5622-d6d787d3a0b1@oracle.com>
Message-ID: <CAJwKKmawocU3nw=CBCob_E-uG-DzXwU5ODkBUeC+13jg3VqCdw@mail.gmail.com>

On Wed, Jul 18, 2018 at 11:28 PM, Phil Race <philip.race at oracle.com> wrote:
> The review for the original fix was actually on awt-dev which probably was
> correct
> and so this should be there too.

Hi Phil,

Thanks for the review, and I apologise for posting it to 2d-dev, that
was out of habit :)

> I hadn't seen the thread so had to go read it .. but it was so long ago I'd
> probably have had to re-read it anyway. But it was not so easy to find
> since it did not have the bug ID in the subject !
> http://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010742.html
> http://mail.openjdk.java.net/pipermail/awt-dev/2016-April/010996.html
> http://mail.openjdk.java.net/pipermail/awt-dev/2016-May/011370.html

Right, thanks again for linking the relevant thread information, I
didn't post it as it was in the bug description, but indeed is a nice
courtesy for the reviewer, I'll make sure to have it linked next time
in the email request too.

> Since it is changed, yes, being able to point to this review thread is
> likely
> something the 8u-dev maintainers would ask you for.
>
> It looks OK to me although I don't grok why the order here in 8u
>
> 302     if (isXCompositeDisplay(awt_display, adata->awt_visInfo.screen) &&
>  303         hasXCompositeOverlayExtension(awt_display))
>
> is reversed from what you had in 9 :
> 309         if (hasXCompositeOverlayExtension(awt_display) &&
>  310             isXCompositeDisplay(awt_display,
> adata->awt_visInfo.screen))
>

Eh.. This is because the current patch is based on what I had on the
RPM, which is an older version of the patch I pushed for 9, before the
additional gtk code, for some reason the line was inverted initially,
I changed this in the 9 patch as it is indeed more logical. Thanks for
spotting this as I completely missed it (good that we have reviews for
backports too!).

It's fixed in this new webrev:

http://cr.openjdk.java.net/~neugens/8150954/webrev-jdk8u.01/jdk.patch

Cheers,
Mario

-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From philip.race at oracle.com  Thu Jul 19 20:43:44 2018
From: philip.race at oracle.com (Phil Race)
Date: Thu, 19 Jul 2018 13:43:44 -0700
Subject: [OpenJDK 2D-Dev] Request for re-reviewl: Backport of
 JDK-8150954: Taking screenshots on x11 composite desktop produce wrong
 result
In-Reply-To: <CAJwKKmawocU3nw=CBCob_E-uG-DzXwU5ODkBUeC+13jg3VqCdw@mail.gmail.com>
References: <CAJwKKmYrgu7Sk=PagC_F=3AMpvRWe=akh4XVbW+nRQ1rkdyyxQ@mail.gmail.com>
 <3e183051-31b5-f9b6-5622-d6d787d3a0b1@oracle.com>
 <CAJwKKmawocU3nw=CBCob_E-uG-DzXwU5ODkBUeC+13jg3VqCdw@mail.gmail.com>
Message-ID: <94afc6e3-5b46-552e-c53a-da86a6dd6a95@oracle.com>

+1

-phil.

On 07/19/2018 05:33 AM, Mario Torre wrote:
> On Wed, Jul 18, 2018 at 11:28 PM, Phil Race <philip.race at oracle.com> wrote:
>> The review for the original fix was actually on awt-dev which probably was
>> correct
>> and so this should be there too.
> Hi Phil,
>
> Thanks for the review, and I apologise for posting it to 2d-dev, that
> was out of habit :)
>
>> I hadn't seen the thread so had to go read it .. but it was so long ago I'd
>> probably have had to re-read it anyway. But it was not so easy to find
>> since it did not have the bug ID in the subject !
>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010742.html
>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-April/010996.html
>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-May/011370.html
> Right, thanks again for linking the relevant thread information, I
> didn't post it as it was in the bug description, but indeed is a nice
> courtesy for the reviewer, I'll make sure to have it linked next time
> in the email request too.
>
>> Since it is changed, yes, being able to point to this review thread is
>> likely
>> something the 8u-dev maintainers would ask you for.
>>
>> It looks OK to me although I don't grok why the order here in 8u
>>
>> 302     if (isXCompositeDisplay(awt_display, adata->awt_visInfo.screen) &&
>>   303         hasXCompositeOverlayExtension(awt_display))
>>
>> is reversed from what you had in 9 :
>> 309         if (hasXCompositeOverlayExtension(awt_display) &&
>>   310             isXCompositeDisplay(awt_display,
>> adata->awt_visInfo.screen))
>>
> Eh.. This is because the current patch is based on what I had on the
> RPM, which is an older version of the patch I pushed for 9, before the
> additional gtk code, for some reason the line was inverted initially,
> I changed this in the 9 patch as it is indeed more logical. Thanks for
> spotting this as I completely missed it (good that we have reviews for
> backports too!).
>
> It's fixed in this new webrev:
>
> http://cr.openjdk.java.net/~neugens/8150954/webrev-jdk8u.01/jdk.patch
>
> Cheers,
> Mario
>


From takiguc at linux.vnet.ibm.com  Wed Jul 25 10:29:46 2018
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Wed, 25 Jul 2018 19:29:46 +0900
Subject: [OpenJDK 2D-Dev] [11] Cannot use italic font style with MS Gothic
	and MS Mincho fonts
Message-ID: <cbf19ffba3f71a0d99e2057eda2d7b31@linux.vnet.ibm.com>

Hello.
I'm using jdk-11+23 build on Japanese Windows 7.

I ran Font2DTest Demo, then select like:
Font: MS Mincho
Range: Basic Latin
Method: drawString
Size: 24
Style: Italic

But style was not changed to Italic.
Antialiasing and Fractional Metrics did not affect this issue.

I assume it's side-effect for:
8204929: Fonts with embedded bitmaps are not always rotated

Could you check it ?

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.


From philip.race at oracle.com  Thu Jul 26 19:42:01 2018
From: philip.race at oracle.com (Phil Race)
Date: Thu, 26 Jul 2018 12:42:01 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8204391: Colors with alpha are painted
	incorrectly on Linux
Message-ID: <5271aa00-4238-8489-b125-c149dff9f021@oracle.com>

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

There is a long evaluation in the bug report, so what I write here is 
just a summary.

This is a regression introduced by 
https://bugs.openjdk.java.net/browse/JDK-8176795
and specific to the Xrender pipeline

The bug is that when using colors with alpha, the alpha is being ignored 
and the colour
copied rather than blended, since we no longer pass the "pre-multiplied" 
flag as false.

The fix is to pre-multiply the colour when storing as a pixel even for 
an opaque xrender surface.

With this fix automated jtreg tests, and tck tests pass, as well as the 
manual TCK test that was failing.

Additionally the supplied regression test passes on all platforms.

-phil




From jayathirth.d.v at oracle.com  Fri Jul 27 09:27:13 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Fri, 27 Jul 2018 02:27:13 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] RFR: 8204391: Colors with alpha are painted
 incorrectly on Linux
In-Reply-To: <5271aa00-4238-8489-b125-c149dff9f021@oracle.com>
References: <5271aa00-4238-8489-b125-c149dff9f021@oracle.com>
Message-ID: <59a75f5e-d35c-454a-9fbb-13924b74817e@default>

Hi Phil,

Thanks for fixing the regression introduced by https://bugs.openjdk.java.net/browse/JDK-8176795 .
I went through the changes present in http://cr.openjdk.java.net/~prr/8204931/ and it looks fine.
I have added detail review summary in the bug itself.

We can also ask Clemens to take a look at the change.

Regards,
Jay

-----Original Message-----
From: Phil Race 
Sent: Friday, July 27, 2018 1:12 AM
To: 2d-dev
Subject: [OpenJDK 2D-Dev] RFR: 8204391: Colors with alpha are painted incorrectly on Linux

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

There is a long evaluation in the bug report, so what I write here is just a summary.

This is a regression introduced by
https://bugs.openjdk.java.net/browse/JDK-8176795
and specific to the Xrender pipeline

The bug is that when using colors with alpha, the alpha is being ignored and the colour copied rather than blended, since we no longer pass the "pre-multiplied" 
flag as false.

The fix is to pre-multiply the colour when storing as a pixel even for an opaque xrender surface.

With this fix automated jtreg tests, and tck tests pass, as well as the manual TCK test that was failing.

Additionally the supplied regression test passes on all platforms.

-phil




From prasanta.sadhukhan at oracle.com  Fri Jul 27 10:11:07 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 27 Jul 2018 15:41:07 +0530
Subject: [OpenJDK 2D-Dev] RFR: 8204391: Colors with alpha are painted
 incorrectly on Linux
In-Reply-To: <5271aa00-4238-8489-b125-c149dff9f021@oracle.com>
References: <5271aa00-4238-8489-b125-c149dff9f021@oracle.com>
Message-ID: <b7232ce8-c0ee-9f2c-df60-5c613aec59c0@oracle.com>

Fix looks good to me.

A nit in the test

61 SwingUtilities.invokeAndWait(() -> createAndShowGUI());
Since awt Frame is being created and not JFrame, there is no need of 
using EDT.

Regards
Prasanta
On 7/27/2018 1:12 AM, Phil Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8204931
> Webrev: http://cr.openjdk.java.net/~prr/8204931/
>
> There is a long evaluation in the bug report, so what I write here is 
> just a summary.
>
> This is a regression introduced by 
> https://bugs.openjdk.java.net/browse/JDK-8176795
> and specific to the Xrender pipeline
>
> The bug is that when using colors with alpha, the alpha is being 
> ignored and the colour
> copied rather than blended, since we no longer pass the 
> "pre-multiplied" flag as false.
>
> The fix is to pre-multiply the colour when storing as a pixel even for 
> an opaque xrender surface.
>
> With this fix automated jtreg tests, and tck tests pass, as well as 
> the manual TCK test that was failing.
>
> Additionally the supplied regression test passes on all platforms.
>
> -phil
>
>
>


From takiguc at linux.vnet.ibm.com  Fri Jul 27 11:22:44 2018
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Fri, 27 Jul 2018 20:22:44 +0900
Subject: [OpenJDK 2D-Dev] [11] Cannot use italic font style with MS
 Gothic	and MS Mincho fonts
In-Reply-To: <cbf19ffba3f71a0d99e2057eda2d7b31@linux.vnet.ibm.com>
References: <cbf19ffba3f71a0d99e2057eda2d7b31@linux.vnet.ibm.com>
Message-ID: <9d84ad21937adbb383a431970c5aaf01@linux.vnet.ibm.com>

Hello.

According to my investigation, FT_Render_Glyph() was not called
even if FT_GlyphSlot_Oblique() was called.

=========
     if (ftglyph->format == FT_GLYPH_FORMAT_OUTLINE) {
         FT_Render_Glyph(ftglyph, FT_LOAD_TARGET_MODE(target)); <<===
     }
=========

It seemed FT_Load_Glyph() and renderFlags affected this issue.

On my Windows,
For "MS Mincho" with italic, renderFlags was "FT_LOAD_TARGET_MONO | 
FT_LOAD_NO_BITMAP | FT_LOAD_RENDER".
I also tested "Meiryo" font (it could handle italic style)
For "Meiryo" with italic, renderFlags was "FT_LOAD_TARGET_MONO | 
FT_LOAD_RENDER".

I think, after FT_LOAD_NO_BITMAP is turned on, FT_LOAD_RENDER should be 
turned off.
So how about following fix ?

=========
diff -r 1edcf36fe15f 
src/java.desktop/share/native/libfontmanager/freetypeScaler.c
--- a/src/java.desktop/share/native/libfontmanager/freetypeScaler.c	Wed 
Jul 18 11:57:51 2018 -0400
+++ b/src/java.desktop/share/native/libfontmanager/freetypeScaler.c	Fri 
Jul 27 19:44:12 2018 +0900
@@ -700,6 +700,9 @@

      if (!context->useSbits) {
          renderFlags |= FT_LOAD_NO_BITMAP;
+        if (context->doBold || context->doItalize) {
+            renderFlags &= ~FT_LOAD_RENDER;
+        }
      }

      /* NB: in case of non identity transform
=========


On 2018-07-25 19:29, Ichiroh Takiguchi wrote:
> Hello.
> I'm using jdk-11+23 build on Japanese Windows 7.
> 
> I ran Font2DTest Demo, then select like:
> Font: MS Mincho
> Range: Basic Latin
> Method: drawString
> Size: 24
> Style: Italic
> 
> But style was not changed to Italic.
> Antialiasing and Fractional Metrics did not affect this issue.
> 
> I assume it's side-effect for:
> 8204929: Fonts with embedded bitmaps are not always rotated
> 
> Could you check it ?
> 
> Thanks,
> Ichiroh Takiguchi
> IBM Japan, Ltd.


From philip.race at oracle.com  Fri Jul 27 15:04:14 2018
From: philip.race at oracle.com (Philip Race)
Date: Fri, 27 Jul 2018 08:04:14 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8204391: Colors with alpha are painted
 incorrectly on Linux
In-Reply-To: <b7232ce8-c0ee-9f2c-df60-5c613aec59c0@oracle.com>
References: <5271aa00-4238-8489-b125-c149dff9f021@oracle.com>
 <b7232ce8-c0ee-9f2c-df60-5c613aec59c0@oracle.com>
Message-ID: <5B5B346E.2020902@oracle.com>

Actually, although the recommendation is not "as strong", it is still
recommended to use the EDT for initialising AWT apps.
You'll find the same in some other tests I think.
In any case it is just a harmless precaution.

-phil.

On 7/27/18, 3:11 AM, Prasanta Sadhukhan wrote:
> Fix looks good to me.
>
> A nit in the test
>
> 61 SwingUtilities.invokeAndWait(() -> createAndShowGUI());
> Since awt Frame is being created and not JFrame, there is no need of 
> using EDT.
>
> Regards
> Prasanta
> On 7/27/2018 1:12 AM, Phil Race wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8204931
>> Webrev: http://cr.openjdk.java.net/~prr/8204931/
>>
>> There is a long evaluation in the bug report, so what I write here is 
>> just a summary.
>>
>> This is a regression introduced by 
>> https://bugs.openjdk.java.net/browse/JDK-8176795
>> and specific to the Xrender pipeline
>>
>> The bug is that when using colors with alpha, the alpha is being 
>> ignored and the colour
>> copied rather than blended, since we no longer pass the 
>> "pre-multiplied" flag as false.
>>
>> The fix is to pre-multiply the colour when storing as a pixel even 
>> for an opaque xrender surface.
>>
>> With this fix automated jtreg tests, and tck tests pass, as well as 
>> the manual TCK test that was failing.
>>
>> Additionally the supplied regression test passes on all platforms.
>>
>> -phil
>>
>>
>>
>

From philip.race at oracle.com  Fri Jul 27 15:09:12 2018
From: philip.race at oracle.com (Philip Race)
Date: Fri, 27 Jul 2018 08:09:12 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8204391: Colors with alpha are painted
 incorrectly on Linux
In-Reply-To: <59a75f5e-d35c-454a-9fbb-13924b74817e@default>
References: <5271aa00-4238-8489-b125-c149dff9f021@oracle.com>
 <59a75f5e-d35c-454a-9fbb-13924b74817e@default>
Message-ID: <5B5B3598.1000808@oracle.com>

If Clemens can also look at it, that would be great, but if he does not 
have time
right now, I would not like to hold it up, since its a tck-red for 11.

-phil.

On 7/27/18, 2:27 AM, Jayathirth D V wrote:
> Hi Phil,
>
> Thanks for fixing the regression introduced by https://bugs.openjdk.java.net/browse/JDK-8176795 .
> I went through the changes present in http://cr.openjdk.java.net/~prr/8204931/ and it looks fine.
> I have added detail review summary in the bug itself.
>
> We can also ask Clemens to take a look at the change.
>
> Regards,
> Jay
>
> -----Original Message-----
> From: Phil Race
> Sent: Friday, July 27, 2018 1:12 AM
> To: 2d-dev
> Subject: [OpenJDK 2D-Dev] RFR: 8204391: Colors with alpha are painted incorrectly on Linux
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8204931
> Webrev: http://cr.openjdk.java.net/~prr/8204931/
>
> There is a long evaluation in the bug report, so what I write here is just a summary.
>
> This is a regression introduced by
> https://bugs.openjdk.java.net/browse/JDK-8176795
> and specific to the Xrender pipeline
>
> The bug is that when using colors with alpha, the alpha is being ignored and the colour copied rather than blended, since we no longer pass the "pre-multiplied"
> flag as false.
>
> The fix is to pre-multiply the colour when storing as a pixel even for an opaque xrender surface.
>
> With this fix automated jtreg tests, and tck tests pass, as well as the manual TCK test that was failing.
>
> Additionally the supplied regression test passes on all platforms.
>
> -phil
>
>
>

From philip.race at oracle.com  Sat Jul 28 18:07:44 2018
From: philip.race at oracle.com (Philip Race)
Date: Sat, 28 Jul 2018 11:07:44 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] RFR: 8208466: Fix potential memory leak in
	harfbuzz shaping
Message-ID: <5B5CB0F0.8080002@oracle.com>

bug: https://bugs.openjdk.java.net/browse/JDK-8208466
webrev: http://cr.openjdk.java.net/~prr/8208466/

Simple fix for possible memory leaks on error conditions.
This is the same fix as in upstream harfbuzz.

-phil.

From krishna.addepalli at oracle.com  Sun Jul 29 08:41:26 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Sun, 29 Jul 2018 01:41:26 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] RFR: 8208466: Fix potential memory leak in
 harfbuzz shaping
In-Reply-To: <5B5CB0F0.8080002@oracle.com>
References: <5B5CB0F0.8080002@oracle.com>
Message-ID: <5e5b54e9-8100-4a3c-a997-f6177d4a77ab@default>

+1
-Krishna

-----Original Message-----
From: Philip Race 
Sent: Saturday, July 28, 2018 11:38 PM
To: 2d-dev <2d-dev at openjdk.java.net>
Subject: [OpenJDK 2D-Dev] RFR: 8208466: Fix potential memory leak in harfbuzz shaping

bug: https://bugs.openjdk.java.net/browse/JDK-8208466
webrev: http://cr.openjdk.java.net/~prr/8208466/

Simple fix for possible memory leaks on error conditions.
This is the same fix as in upstream harfbuzz.

-phil.

From prasanta.sadhukhan at oracle.com  Mon Jul 30 04:59:00 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Mon, 30 Jul 2018 10:29:00 +0530
Subject: [OpenJDK 2D-Dev] RFR: 8208466: Fix potential memory leak in
 harfbuzz shaping
In-Reply-To: <5B5CB0F0.8080002@oracle.com>
References: <5B5CB0F0.8080002@oracle.com>
Message-ID: <cecba651-3628-ac6f-34da-24dee557f977@oracle.com>

+1

Regards
Prasanta
On 7/28/2018 11:37 PM, Philip Race wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8208466
> webrev: http://cr.openjdk.java.net/~prr/8208466/
>
> Simple fix for possible memory leaks on error conditions.
> This is the same fix as in upstream harfbuzz.
>
> -phil.


From jayathirth.d.v at oracle.com  Mon Jul 30 06:25:19 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Sun, 29 Jul 2018 23:25:19 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] RFR: 8208466: Fix potential memory leak in
 harfbuzz shaping
In-Reply-To: <5B5CB0F0.8080002@oracle.com>
References: <5B5CB0F0.8080002@oracle.com>
Message-ID: <64c87bdf-ce30-4661-afd3-ccc686939ef2@default>

Hi Phil,

Changes are fine.

Thanks,
Jay

-----Original Message-----
From: Philip Race 
Sent: Saturday, July 28, 2018 11:38 PM
To: 2d-dev
Subject: [OpenJDK 2D-Dev] RFR: 8208466: Fix potential memory leak in harfbuzz shaping

bug: https://bugs.openjdk.java.net/browse/JDK-8208466
webrev: http://cr.openjdk.java.net/~prr/8208466/

Simple fix for possible memory leaks on error conditions.
This is the same fix as in upstream harfbuzz.

-phil.

From philip.race at oracle.com  Mon Jul 30 21:28:39 2018
From: philip.race at oracle.com (Phil Race)
Date: Mon, 30 Jul 2018 14:28:39 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8u: Remove Kodak CMS (KCMS) code from Oracle
	JDK
Message-ID: <2d5563d4-e45d-9a21-66b9-b872e8587394@oracle.com>

This is a request against 8u-dev.

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

In JDK 10 we removed the old closed source KCMS color management library.
Since we expect to support 8u for some years to come, we'd also like to 
remove it from 8u,
since it already superseded there by LCMS and KCMS is just a liability.

The source is closed, but all the make files are in the open make 
directory, hence this RFR

-phil.

From philip.race at oracle.com  Mon Jul 30 21:53:37 2018
From: philip.race at oracle.com (Phil Race)
Date: Mon, 30 Jul 2018 14:53:37 -0700
Subject: [OpenJDK 2D-Dev] RFR 8195615 : libsplashscreen linux ppc64le
 build error after libpng update - was : RE: jdk-hs ppc64le build error,
 probably related to libpng update
In-Reply-To: <08465e0a6f6f4c45a2706194ae7987b6@sap.com>
References: <3bc757e506ae40c5aad26a217fc1eb19@sap.com>
 <077043e8-8c24-e5d1-d30b-fae2a1398abe@oracle.com>
 <b10230cba092402499a4eed387f87d35@sap.com>
 <08465e0a6f6f4c45a2706194ae7987b6@sap.com>
Message-ID: <375858af-0d82-7062-fa80-45bcb50d057c@oracle.com>

Was this reported upstream ? Was it fixed in some way there ?

I'm upgrading libpng again in JDK 11 and it appears this change will 
regress when I push
http://cr.openjdk.java.net/~prr/8208353/src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h.udiff.html

because it is not in upstream .. but perhaps it was resolved there in 
some other way ?

-phil.

On 01/18/2018 01:28 AM, Doerr, Martin wrote:
>
> Hi Matthias,
>
> thanks for fixing. Looks good.
>
> Reviewed and pushed to jdk10.
>
> Best regards,
>
> Martin
>
> *From:*Baesken, Matthias
> *Sent:* Donnerstag, 18. Januar 2018 07:53
> *To:* Phil Race <philip.race at oracle.com>; 2d-dev at openjdk.java.net
> *Cc:* Doerr, Martin <martin.doerr at sap.com>; Simonis, Volker 
> <volker.simonis at sap.com>; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> *Subject:* RE: RFR 8195615 : libsplashscreen linux ppc64le build error 
> after libpng update - was : RE: jdk-hs ppc64le build error, probably 
> related to libpng update
>
> Thanks, do I need another review ?
>
>  ( Here I found the names of the libpng authors + current maintainer :
>
> http://www.libpng.org/pub/png/libpng.html
>
> )
>
> Best regards, Matthias
>
> *From:*Phil Race [mailto:philip.race at oracle.com]
> *Sent:* Mittwoch, 17. Januar 2018 22:57
> *To:* Baesken, Matthias <matthias.baesken at sap.com 
> <mailto:matthias.baesken at sap.com>>; 2d-dev at openjdk.java.net 
> <mailto:2d-dev at openjdk.java.net>
> *Cc:* Doerr, Martin <martin.doerr at sap.com 
> <mailto:martin.doerr at sap.com>>; Simonis, Volker 
> <volker.simonis at sap.com <mailto:volker.simonis at sap.com>>
> *Subject:* Re: RFR 8195615 : libsplashscreen linux ppc64le build error 
> after libpng update - was : RE: jdk-hs ppc64le build error, probably 
> related to libpng update
>
> This looks fine to me.
>
> Martin asked (a while ago) if I knew where to report this upstream.
>
> I can only suggest what I find via search as being the libpng bug 
> tracker :
> https://sourceforge.net/p/libpng/bugs/
>
> -phil
>
> On 01/17/2018 06:45 AM, Baesken, Matthias wrote:
>
>     Hello I created a  bug + webrev  for  the  png /  libsplashscreen 
>     build  issue seen on linux ppc64le .
>
>     The error because of undefined png_init_filter_functions_vsx  is  :
>
>     /open_jdk/jdk_2_build/linuxppc64le/support/native/java.desktop/libsplashscreen/pngrutil.o:
>     In function `png_init_filter_functions':
>     /open_jdk/jdk_2/jdk/src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c:4134:
>     undefined reference to png_init_filter_functions_vsx'
>
>     The issue has been observed on a SLES12 SP1 ppc64le build machine
>     with "gcc version 4.8.5 (SUSE Linux)" .
>
>     Please review .
>
>     Bug :
>
>     https://bugs.openjdk.java.net/browse/JDK-8195615
>
>     Webrev :
>
>     http://cr.openjdk.java.net/~mbaesken/webrevs/8195615/
>     <http://cr.openjdk.java.net/%7Embaesken/webrevs/8195615/>
>
>     Thanks, Matthias
>
>     *From:*Philip Race [mailto:philip.race at oracle.com]
>     *Sent:* Donnerstag, 28. Dezember 2017 18:09
>     *To:* Baesken, Matthias <matthias.baesken at sap.com>
>     <mailto:matthias.baesken at sap.com>
>     *Cc:* 2d-dev at openjdk.java.net <mailto:2d-dev at openjdk.java.net>;
>     Doerr, Martin <martin.doerr at sap.com>
>     <mailto:martin.doerr at sap.com>; Simonis, Volker
>     <volker.simonis at sap.com> <mailto:volker.simonis at sap.com>
>     *Subject:* Re: jdk-hs ppc64le build error, probably related to
>     libpng update
>
>     This all sounds fine to me.
>     Definitely we should report this upstream to see what they say but
>     clearly we aren't bound to wait for an answer from there since this is
>     a build breakage for PPC. If someone upstream
>     comes back with a better answer we can update the fix.
>
>     I think this png update will get backported to 8u at some point ..
>     the PPC port is supported on 8u, isn't it ? So we'll want to make
>     sure we have the fix before we do the backport.
>
>     -phil.
>
>     On 12/28/17, 5:07 AM, Baesken, Matthias wrote:
>
>         Hi Phil,  I think your idea to guard with
>
>         #ifdef PNG_POWERPC_VSX_API_SUPPORTED
>
>         Is fine, should I prepare a webrev   using this guard ?
>
>           * Wrapping in that check might be OK (for
>             PNG_POWERPC_VSX_API_SUPPORTED) but you'll want to report
>             this upstream.
>
>         Yes it is a good idea to report this upstream as well  at libpng.
>
>         Best regards, Matthias
>
>         *From:*Phil Race [mailto:philip.race at oracle.com]
>         *Sent:* Freitag, 22. Dezember 2017 19:08
>         *To:* Baesken, Matthias <matthias.baesken at sap.com>
>         <mailto:matthias.baesken at sap.com>; 2d-dev at openjdk.java.net
>         <mailto:2d-dev at openjdk.java.net>
>         *Cc:* Doerr, Martin <martin.doerr at sap.com>
>         <mailto:martin.doerr at sap.com>; Simonis, Volker
>         <volker.simonis at sap.com> <mailto:volker.simonis at sap.com>
>         *Subject:* Re: jdk-hs ppc64le build error, probably related to
>         libpng update
>
>         I expect that will fix it but I wonder if the problem is that
>         all of this needs
>         to be guarded by checking :-
>
>         #ifdef PNG_POWERPC_VSX_API_SUPPORTED
>
>         It looks to me configure would have set that if it had been
>         run on PPC AND
>         you have passed --enable-powerpc-vsx to configure
>
>         But of course I did not.
>
>         And someone can set it unsupported anyway.
>
>         So this seems like a libpng bug.
>
>         Wrapping in that check might be OK (for
>         PNG_POWERPC_VSX_API_SUPPORTED) but
>         you'll want to report this upstream.
>
>         I have no intention of pulling in the accelerated code .. even
>         for intel ... this
>         library is used only for splashscreen.
>
>         -phil.
>
>
>
>         On 12/21/2017 07:13 AM, Baesken, Matthias wrote:
>
>             >Do  you have  a version of libpng  available that contains  the
>             missing function png_init_filter_functions_vsx  ?
>
>             >Or do you have an idea where it should come from (I cannot find
>             it in the main libpng sources).
>
>             >To fix the build, we could probably disable  the part bringing
>             in png_init_filter_functions_vsx   in
>             png_init_filter_functions_vsx  .
>
>             Hello, small update -  here is a fix that  disables the
>             libpng  vsx optimizations  on ppc64  (and fixes the build
>             issue).
>
>             Should I prepare a webrev ?  Or how to get  a ppc64 le  /
>             be    png_init_filter_functions_vsx implementation ?
>
>             Best regards, Matthias
>
>             -----------------------
>
>             diff -r d55bee3727de
>             src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h
>
>             ---
>             a/src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h
>             Tue Dec 19 17:31:53 2017 -0500
>
>             +++
>             b/src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h
>             Wed Dec 20 17:16:01 2017 +0100
>
>             @@ -220,12 +220,15 @@
>
>             #  endif
>
>             #endif
>
>             +/* for now avoid the ppc64 vsx optimizations */
>
>             #ifndef PNG_POWERPC_VSX_OPT
>
>             -#  if defined(__PPC64__) && defined(__ALTIVEC__) &&
>             defined(__VSX__)
>
>             -# define PNG_POWERPC_VSX_OPT 2
>
>             -#  else
>
>             +/*
>
>             + * #  if defined(__PPC64__) && defined(__ALTIVEC__) &&
>             defined(__VSX__)
>
>             + * # define PNG_POWERPC_VSX_OPT 2
>
>             + * #  else
>
>             + */
>
>             #     define PNG_POWERPC_VSX_OPT 0
>
>             -#  endif
>
>             +/* #  endif */
>
>             #endif
>
>              #ifndef PNG_INTEL_SSE_OPT
>
>             -----------------------
>
>             *From:*Baesken, Matthias
>             *Sent:* Mittwoch, 20. Dezember 2017 13:04
>             *To:* Phil Race (philip.race at oracle.com
>             <mailto:philip.race at oracle.com>) <philip.race at oracle.com>
>             <mailto:philip.race at oracle.com>
>             *Cc:* Doerr, Martin <martin.doerr at sap.com>
>             <mailto:martin.doerr at sap.com>; Simonis, Volker
>             <volker.simonis at sap.com> <mailto:volker.simonis at sap.com>;
>             2d-dev at openjdk.java.net <mailto:2d-dev at openjdk.java.net>
>             *Subject:* jdk-hs ppc64le build error, probably related to
>             libpng update
>
>             Hi Phil, it looks like  the recent  png lib change
>
>             8183960: Upgrade to libpng 1.6.34
>
>             http://hg.openjdk.java.net/jdk/hs/rev/791d551bcdb8
>
>             +#if PNG_POWERPC_VSX_OPT > 0
>
>             +#  define PNG_FILTER_OPTIMIZATIONS
>             png_init_filter_functions_vsx
>
>             +#  define PNG_POWERPC_VSX_IMPLEMENTATION 1
>
>             +#endif
>
>             Causes  build errors  in  our  linuxppc64le  openjdk 
>             jdk-hs (fast)dbg  build .
>
>             We get  this linker error :
>
>             pngrutil.c:(.text+0x4824): undefined reference to
>             `png_init_filter_functions_vsx'
>
>             Do  you have  a version of libpng  available that
>             contains  the missing function
>             png_init_filter_functions_vsx  ?
>
>             Or do you have an idea where it should come from (I cannot
>             find it in the main libpng sources).
>
>             To fix the build, we could probably disable  the part
>             bringing in png_init_filter_functions_vsx   in
>             png_init_filter_functions_vsx  .
>
>             Thanks, Matthias
>
>             Error message :
>
>               * /hs/support/native/java.desktop/libsplashscreen/pngrutil.o:
>                 In function `png_read_filter_row':
>               * pngrutil.c:(.text+0x4824): undefined reference to
>                 `png_init_filter_functions_vsx'
>               * collect2: error: ld returned 1 exit status
>               * Awt2dLibraries.gmk:928: recipe for target
>                 '/hs/support/modules_libs/java.desktop/libsplashscreen.so'
>                 failed
>

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

From magnus.ihse.bursie at oracle.com  Tue Jul 31 19:18:57 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 31 Jul 2018 12:18:57 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8u: Remove Kodak CMS (KCMS) code from
	Oracle JDK
In-Reply-To: <2d5563d4-e45d-9a21-66b9-b872e8587394@oracle.com>
References: <2d5563d4-e45d-9a21-66b9-b872e8587394@oracle.com>
Message-ID: <51235F7F-06C1-47ED-95E8-78F68F16B6EF@oracle.com>

Looks good to me. 

/Magnus

> 30 juli 2018 kl. 14:28 skrev Phil Race <philip.race at oracle.com>:
> 
> This is a request against 8u-dev.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8183979
> Webrev: http://cr.openjdk.java.net/~prr/8183979.8u/
> 
> In JDK 10 we removed the old closed source KCMS color management library.
> Since we expect to support 8u for some years to come, we'd also like to remove it from 8u,
> since it already superseded there by LCMS and KCMS is just a liability.
> 
> The source is closed, but all the make files are in the open make directory, hence this RFR
> 
> -phil.


From engineering at hummeling.com  Fri Jul 20 14:55:26 2018
From: engineering at hummeling.com (Ralph Hummeling)
Date: Fri, 20 Jul 2018 14:55:26 -0000
Subject: [OpenJDK 2D-Dev] ArcIterator#btan(double)
Message-ID: <5c6de6b53bb233009fa9216a445abcc3@hummeling.com>

Dear Java 2D dev team,

I came across your java.awt.geom.ArcIterator class in which an arc 
Bezier control point segment length is determined in method 
btan(double). You arrive at the following equation:
4/3*(1 - cos(a/2))/(sin(a/2))

It is mentioned that this can return NaN for small "a" and so it is 
written as:
4/3*(sin(a/2))/(1 + cos(a/2))

Please note that this relation can also be written as follows:
4/3*tan(a/4)

A performance increase and no NaN issues ;-)


Kind regards,

Ralph Hummeling
+316 5758 1679
Hummeling Engineering BV
www.hummeling.com