From suenaga at oss.nttdata.com  Mon Aug  3 06:00:04 2020
From: suenaga at oss.nttdata.com (Yasumasa Suenaga)
Date: Mon, 3 Aug 2020 15:00:04 +0900
Subject: [OpenJDK 2D-Dev] <AWT Dev> PING: RFR: 8249215:
 JFrame::setVisible crashed with -Dfile.encoding=UTF-8
In-Reply-To: <93345020-5463-1078-61f6-5f305cea1449@oss.nttdata.com>
References: <2502c57c-544a-eb60-3a11-c3c0bc2ee852@oss.nttdata.com>
 <5A6C958B-722E-4574-8258-D404C77D5FFD@ORACLE.COM>
 <3153dd5e-4a01-7e9a-2508-60233604dbbf@oss.nttdata.com>
 <a3c5447c-c64d-488c-85b4-af4c08116831@default>
 <1ba1a832-45cd-8f50-2b5e-a8205d521975@oss.nttdata.com>
 <5F1EEC96.5020509@oracle.com>
 <8a5a1d0f-7396-b086-b97d-1eafb251600a@oss.nttdata.com>
 <a090bca1-5009-925f-9b99-3a139a982b27@oracle.com>
 <ba933e2f-1189-7f59-3ed3-ceb51ce6a417@oracle.com>
 <c035372c-c93f-ae0a-e0ae-0a4871fd04e4@oss.nttdata.com>
 <5F2039A4.6040807@oracle.com>
 <2d4b58c3-93c1-5585-f4b4-e26efa6b859d@oss.nttdata.com>
 <5F20C7A4.2010002@oracle.com>
 <98367096-a1d4-9a35-5e35-3ce27b96bc5c@oss.nttdata.com>
 <5F20CEFE.80806@oracle.com>
 <abbfc11f-f88a-5eb5-b238-5f05e75ada4c@oss.nttdata.com>
 <fdb5fe7f-f46d-ef78-fb2f-506eab0cf1b8@oracle.com>
 <b4451f39-be61-72a6-2a6f-d0fc3f94a5ea@oss.nttdata.com>
 <05267f63-59f3-636c-c172-45da7f4526ef@oracle.com>
 <93345020-5463-1078-61f6-5f305cea1449@oss.nttdata.com>
Message-ID: <295cddb5-94ca-9949-b3ca-c88296bb7fca@oss.nttdata.com>

Hi Sergey,

Do you have any comments on this webrev?

   http://cr.openjdk.java.net/~ysuenaga/JDK-8249215/webrev.03/

If not, I will push it to jdk/client.


Thanks,

Yasumasa


On 2020/07/30 13:32, Yasumasa Suenaga wrote:
> On 2020/07/30 12:20, Sergey Bylokhov wrote:
>> On 29.07.2020 19:37, Yasumasa Suenaga wrote:
>>> On 2020/07/30 11:03, Sergey Bylokhov wrote:
>>>> On 28.07.2020 18:52, Yasumasa Suenaga wrote:
>>>>> Hi Phil, Sergey,
>>>>>
>>>>> Sorry, I missed. null is WComponentPeer::pData, not defaultFont.
>>>>
>>>> Could you please clarify in what exact place access to the null pData in WComponentPeer caused a crash?
>>>
>>> src/java.desktop/windows/native/libawt/windows/awt_Component.cpp
>>>
>>> 6032???????? AwtFont *awtFont = (AwtFont *)env->GetLongField(font, AwtFont::pDataID);
>>> 6033???????? if (awtFont == NULL) {
>>> 6034???????????? /*arguments of AwtFont::Create are changed for multifont component */
>>> 6035???????????? awtFont = AwtFont::Create(env, font);
>>> 6036???????? }
>>> 6037???????? env->SetLongField(font, AwtFont::pDataID, (jlong)awtFont);
>>> 6038
>>> 6039???????? c->SetFont(awtFont); // <--
>>>
>>> awtFont in above is NULL.
>>
>> So the reason is that AwtFont::Create returns NULL, and if you take a look to that method
>> there are a few cases when we could return NULL or return 0. Should not all that "returns"
>> be removed? or all results of its usage wrapped by the "if(awtFont!=null)".
>> Or it is fine as-is?
> 
> I think it is fine as-is with my proposal (webrev.03).
> 
> AwtFont::Create() would call GetComponentForName(), then it returns component font name from WFontConfiguration::getTextComponentForName. It is the method what I fixed in this change!
> 
> 
> Thanks,
> 
> Yasumasa

From Sergey.Bylokhov at oracle.com  Mon Aug  3 06:06:49 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sun, 2 Aug 2020 23:06:49 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> PING: RFR: 8249215:
 JFrame::setVisible crashed with -Dfile.encoding=UTF-8
In-Reply-To: <295cddb5-94ca-9949-b3ca-c88296bb7fca@oss.nttdata.com>
References: <2502c57c-544a-eb60-3a11-c3c0bc2ee852@oss.nttdata.com>
 <3153dd5e-4a01-7e9a-2508-60233604dbbf@oss.nttdata.com>
 <a3c5447c-c64d-488c-85b4-af4c08116831@default>
 <1ba1a832-45cd-8f50-2b5e-a8205d521975@oss.nttdata.com>
 <5F1EEC96.5020509@oracle.com>
 <8a5a1d0f-7396-b086-b97d-1eafb251600a@oss.nttdata.com>
 <a090bca1-5009-925f-9b99-3a139a982b27@oracle.com>
 <ba933e2f-1189-7f59-3ed3-ceb51ce6a417@oracle.com>
 <c035372c-c93f-ae0a-e0ae-0a4871fd04e4@oss.nttdata.com>
 <5F2039A4.6040807@oracle.com>
 <2d4b58c3-93c1-5585-f4b4-e26efa6b859d@oss.nttdata.com>
 <5F20C7A4.2010002@oracle.com>
 <98367096-a1d4-9a35-5e35-3ce27b96bc5c@oss.nttdata.com>
 <5F20CEFE.80806@oracle.com>
 <abbfc11f-f88a-5eb5-b238-5f05e75ada4c@oss.nttdata.com>
 <fdb5fe7f-f46d-ef78-fb2f-506eab0cf1b8@oracle.com>
 <b4451f39-be61-72a6-2a6f-d0fc3f94a5ea@oss.nttdata.com>
 <05267f63-59f3-636c-c172-45da7f4526ef@oracle.com>
 <93345020-5463-1078-61f6-5f305cea1449@oss.nttdata.com>
 <295cddb5-94ca-9949-b3ca-c88296bb7fca@oss.nttdata.com>
Message-ID: <838ad1d9-dd62-f6b8-569d-668f663486b8@oracle.com>

+1

On 02.08.2020 23:00, Yasumasa Suenaga wrote:
> Hi Sergey,
> 
> Do you have any comments on this webrev?
> 
>  ? http://cr.openjdk.java.net/~ysuenaga/JDK-8249215/webrev.03/
> 
> If not, I will push it to jdk/client.
> 
> 
> Thanks,
> 
> Yasumasa
> 
> 
> On 2020/07/30 13:32, Yasumasa Suenaga wrote:
>> On 2020/07/30 12:20, Sergey Bylokhov wrote:
>>> On 29.07.2020 19:37, Yasumasa Suenaga wrote:
>>>> On 2020/07/30 11:03, Sergey Bylokhov wrote:
>>>>> On 28.07.2020 18:52, Yasumasa Suenaga wrote:
>>>>>> Hi Phil, Sergey,
>>>>>>
>>>>>> Sorry, I missed. null is WComponentPeer::pData, not defaultFont.
>>>>>
>>>>> Could you please clarify in what exact place access to the null pData in WComponentPeer caused a crash?
>>>>
>>>> src/java.desktop/windows/native/libawt/windows/awt_Component.cpp
>>>>
>>>> 6032???????? AwtFont *awtFont = (AwtFont *)env->GetLongField(font, AwtFont::pDataID);
>>>> 6033???????? if (awtFont == NULL) {
>>>> 6034???????????? /*arguments of AwtFont::Create are changed for multifont component */
>>>> 6035???????????? awtFont = AwtFont::Create(env, font);
>>>> 6036???????? }
>>>> 6037???????? env->SetLongField(font, AwtFont::pDataID, (jlong)awtFont);
>>>> 6038
>>>> 6039???????? c->SetFont(awtFont); // <--
>>>>
>>>> awtFont in above is NULL.
>>>
>>> So the reason is that AwtFont::Create returns NULL, and if you take a look to that method
>>> there are a few cases when we could return NULL or return 0. Should not all that "returns"
>>> be removed? or all results of its usage wrapped by the "if(awtFont!=null)".
>>> Or it is fine as-is?
>>
>> I think it is fine as-is with my proposal (webrev.03).
>>
>> AwtFont::Create() would call GetComponentForName(), then it returns component font name from WFontConfiguration::getTextComponentForName. It is the method what I fixed in this change!
>>
>>
>> Thanks,
>>
>> Yasumasa


-- 
Best regards, Sergey.

From suenaga at oss.nttdata.com  Mon Aug  3 06:24:59 2020
From: suenaga at oss.nttdata.com (Yasumasa Suenaga)
Date: Mon, 3 Aug 2020 15:24:59 +0900
Subject: [OpenJDK 2D-Dev] <AWT Dev> PING: RFR: 8249215:
 JFrame::setVisible crashed with -Dfile.encoding=UTF-8
In-Reply-To: <838ad1d9-dd62-f6b8-569d-668f663486b8@oracle.com>
References: <2502c57c-544a-eb60-3a11-c3c0bc2ee852@oss.nttdata.com>
 <a3c5447c-c64d-488c-85b4-af4c08116831@default>
 <1ba1a832-45cd-8f50-2b5e-a8205d521975@oss.nttdata.com>
 <5F1EEC96.5020509@oracle.com>
 <8a5a1d0f-7396-b086-b97d-1eafb251600a@oss.nttdata.com>
 <a090bca1-5009-925f-9b99-3a139a982b27@oracle.com>
 <ba933e2f-1189-7f59-3ed3-ceb51ce6a417@oracle.com>
 <c035372c-c93f-ae0a-e0ae-0a4871fd04e4@oss.nttdata.com>
 <5F2039A4.6040807@oracle.com>
 <2d4b58c3-93c1-5585-f4b4-e26efa6b859d@oss.nttdata.com>
 <5F20C7A4.2010002@oracle.com>
 <98367096-a1d4-9a35-5e35-3ce27b96bc5c@oss.nttdata.com>
 <5F20CEFE.80806@oracle.com>
 <abbfc11f-f88a-5eb5-b238-5f05e75ada4c@oss.nttdata.com>
 <fdb5fe7f-f46d-ef78-fb2f-506eab0cf1b8@oracle.com>
 <b4451f39-be61-72a6-2a6f-d0fc3f94a5ea@oss.nttdata.com>
 <05267f63-59f3-636c-c172-45da7f4526ef@oracle.com>
 <93345020-5463-1078-61f6-5f305cea1449@oss.nttdata.com>
 <295cddb5-94ca-9949-b3ca-c88296bb7fca@oss.nttdata.com>
 <838ad1d9-dd62-f6b8-569d-668f663486b8@oracle.com>
Message-ID: <41916307-de6e-8cf9-fd85-612259ac8d23@oss.nttdata.com>

Thanks Sergey!

Yasumasa


On 2020/08/03 15:06, Sergey Bylokhov wrote:
> +1
> 
> On 02.08.2020 23:00, Yasumasa Suenaga wrote:
>> Hi Sergey,
>>
>> Do you have any comments on this webrev?
>>
>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8249215/webrev.03/
>>
>> If not, I will push it to jdk/client.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> On 2020/07/30 13:32, Yasumasa Suenaga wrote:
>>> On 2020/07/30 12:20, Sergey Bylokhov wrote:
>>>> On 29.07.2020 19:37, Yasumasa Suenaga wrote:
>>>>> On 2020/07/30 11:03, Sergey Bylokhov wrote:
>>>>>> On 28.07.2020 18:52, Yasumasa Suenaga wrote:
>>>>>>> Hi Phil, Sergey,
>>>>>>>
>>>>>>> Sorry, I missed. null is WComponentPeer::pData, not defaultFont.
>>>>>>
>>>>>> Could you please clarify in what exact place access to the null pData in WComponentPeer caused a crash?
>>>>>
>>>>> src/java.desktop/windows/native/libawt/windows/awt_Component.cpp
>>>>>
>>>>> 6032???????? AwtFont *awtFont = (AwtFont *)env->GetLongField(font, AwtFont::pDataID);
>>>>> 6033???????? if (awtFont == NULL) {
>>>>> 6034???????????? /*arguments of AwtFont::Create are changed for multifont component */
>>>>> 6035???????????? awtFont = AwtFont::Create(env, font);
>>>>> 6036???????? }
>>>>> 6037???????? env->SetLongField(font, AwtFont::pDataID, (jlong)awtFont);
>>>>> 6038
>>>>> 6039???????? c->SetFont(awtFont); // <--
>>>>>
>>>>> awtFont in above is NULL.
>>>>
>>>> So the reason is that AwtFont::Create returns NULL, and if you take a look to that method
>>>> there are a few cases when we could return NULL or return 0. Should not all that "returns"
>>>> be removed? or all results of its usage wrapped by the "if(awtFont!=null)".
>>>> Or it is fine as-is?
>>>
>>> I think it is fine as-is with my proposal (webrev.03).
>>>
>>> AwtFont::Create() would call GetComponentForName(), then it returns component font name from WFontConfiguration::getTextComponentForName. It is the method what I fixed in this change!
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
> 
> 

From alexey.ivanov at oracle.com  Wed Aug  5 21:49:32 2020
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Wed, 5 Aug 2020 22:49:32 +0100
Subject: [OpenJDK 2D-Dev] RFR : 8200281: Add missing @Override
 annotations in ImageIO plugins
In-Reply-To: <B9657A38-988B-47FE-A50F-EA1B239B9D53@oracle.com>
References: <a070dbc1-b6e3-4e15-977b-615aea669fbd@default>
 <5F19C3AB.80807@oracle.com> <d1ed03a5-f8c9-4ba8-8859-87d0c29ffdff@default>
 <5F1B2175.2080502@oracle.com>
 <7b1e47c0-363b-c537-a761-59c97d0d1e3f@oracle.com>
 <0a1859aa-69d3-4400-b967-ccee3b266359@default>
 <560C9F88-2B3A-4697-8014-73EA0887556A@oracle.com>
 <387bec8e-01a5-46af-98b6-adaa6bfd9b7b@default>
 <B9657A38-988B-47FE-A50F-EA1B239B9D53@oracle.com>
Message-ID: <e00c5b86-7817-7826-612a-b3cc694e2857@oracle.com>

Hi Abhishek,

*BMPImageReader.java*

When @Override is added to anonymous classes, the annotation is not 
aligned to the method declaration; at time the indentation of the method 
declaration is unnecessarily modified:

1937???????????? @Override
1938???????????? public void imageProgress(ImageReader source,
in the original file
1927???????????????? public void imageProgress(ImageReader source,

But it's not easy to see in the webrev because it ignored indent change 
on the lines 1927/1938.

These are misaligned and are seen clearly:
1946???????????? @Override
1958???????????? @Override
1964???????????? @Override
1977???????????? @Override
1988???????????? @Override
1998???????????? @Override

This changes the indentation of the method declaration:
1980???????????? @Override
1981???????????? public void thumbnailPassStarted(ImageReader source,


Missing @Override annotation:
2045???????????????? public Boolean run() {


Since we're doing clean-up, a couple more warning can be addressed:

1. There are several unused imports which can be removed.

2. There are two wildcard imports:
 ? 63 import java.io.*;
 ? 64 import java.nio.*;
Shall we expand them into specific imports or leave as is?

3. The class can be made static:
2019???? private class EmbeddedProgressAdapter implements 
IIOReadProgressListener {


*BMPImageWriter.java*

Missing @Override annotation:
1348???????????????????? public void imageProgress(ImageWriter source, 
float percentageDone) {
1354???????????????????? public void warningOccurred(ImageWriter source, 
int imageIndex, String warning) {

The class can be made static:
1384???? private class IIOWriteProgressAdapter implements 
IIOWriteProgressListener {


*GIFImageWriter.java*

There are a couple unused imports which can be removed.


*JPEGImageReader.java*

Missing @Override annotation:
 ? 91???????????????? public Void run() {
 ?953???????????????????? protected ImageTypeSpecifier produce() {
1811????? public boolean hasNext() {
1825????? public ImageTypeSpecifier next() {
1835????? public void remove() {


*JPEGImageWriter.java*

Missing @Override annotation:
179???????????????? public Void run() {


*PNGImageReader.java*

Missing @Override annotation:
76???? public InputStream nextElement() {
86???? public boolean hasMoreElements() {

This file has been updated since the time this webrev was created; thus 
the copyright update does not apply.


*WBMPImageReader.java*

This file has a wildcard import:
43 import java.io.*;
Shall we expand it as in BMPImageReader.java?


*WBMPImageWriter.java*

Missing @Override annotation:
137???? public boolean canWriteRasters() {


Regards,
Alexey

>> On 30 Jul 2020, at 07:10, Kumar Abhishek <kumar.z.abhishek at oracle.com> wrote:
>>
>> Hi Dmitry,
>>
>> I have updated the year in the copyright section for the modified file.
>> Please find the updated Webrev:-
>> http://cr.openjdk.java.net/~jdv/8200281/webrev.03/
>>
>>
>> Thanks,
>> Abhishek
>>
>> <SNIP>
>>
>> -----Original Message-----
>> From: Alexey Ivanov
>> Sent: Saturday, July 25, 2020 2:38 AM
>> To: Kumar Abhishek <kumar.z.abhishek at oracle.com>
>> Cc: Philip Race <philip.race at oracle.com>; 2d-dev
>> <2d-dev at openjdk.java.net>
>> Subject: Re: [OpenJDK 2D-Dev] RFR : 8200281: Add missing @Override
>> annotations in ImageIO plugins
>>
>> Hi Abhishek,
>>
>> <SNIP>
>>
>> So the patch is incomplete.
>> Please verify you add @Override annotation to all overridden methods in these classes.
>>
>>
>> Regards,
>> Alexey

From alexey.ivanov at oracle.com  Wed Aug  5 21:54:47 2020
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Wed, 5 Aug 2020 22:54:47 +0100
Subject: [OpenJDK 2D-Dev] RFR : 8200281: Add missing @Override
 annotations in ImageIO plugins
In-Reply-To: <e00c5b86-7817-7826-612a-b3cc694e2857@oracle.com>
References: <a070dbc1-b6e3-4e15-977b-615aea669fbd@default>
 <5F19C3AB.80807@oracle.com> <d1ed03a5-f8c9-4ba8-8859-87d0c29ffdff@default>
 <5F1B2175.2080502@oracle.com>
 <7b1e47c0-363b-c537-a761-59c97d0d1e3f@oracle.com>
 <0a1859aa-69d3-4400-b967-ccee3b266359@default>
 <560C9F88-2B3A-4697-8014-73EA0887556A@oracle.com>
 <387bec8e-01a5-46af-98b6-adaa6bfd9b7b@default>
 <B9657A38-988B-47FE-A50F-EA1B239B9D53@oracle.com>
 <e00c5b86-7817-7826-612a-b3cc694e2857@oracle.com>
Message-ID: <3cb14383-8c0f-1ac1-c8b3-a94119679e8c@oracle.com>

There are also several unused imports in WBMPImageWriter.java which can 
be removed.

On 05/08/2020 22:49, Alexey Ivanov wrote:
> *WBMPImageWriter.java*
>
> Missing @Override annotation:
> 137???? public boolean canWriteRasters() { 
-- 
Regards,
Alexey

From philip.race at oracle.com  Thu Aug  6 01:46:59 2020
From: philip.race at oracle.com (Philip Race)
Date: Wed, 05 Aug 2020 18:46:59 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8240487 : Cleanup whitespace in .cc, .hh, .m,
 and .mm files
Message-ID: <5F2B6113.5030909@oracle.com>

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

In advance of the move to Project Skara/git it is desirable to clean up 
whitespace in source files
that are not currently checked by jcheck so we can add these extensions 
to jcheck at that time.

The fix is therefore to remove tabs and trailing spaces.

The 3rd party harfbuzz library has .cc and .hh files but there are no 
current violations there
since I've cleaned those up when importing harfbuzz upgrades.

There is one JDK file that relates to those that inherited tabs that is 
fixed.

But almost all the fixes are in Objective C .m and .mm files.
JDK has no examples of .mm but JavaFX does so I was looking just to be sure.

And all but one of the .m violations are in the desktop module which is 
mainly because
that is where all but 5 of the Objective-C files are.

The only non-desktop violator is
./jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m
and that is included in this webrev and why I've included 
serviceability-dev.

-phil.

From chris.plummer at oracle.com  Thu Aug  6 03:12:38 2020
From: chris.plummer at oracle.com (Chris Plummer)
Date: Wed, 5 Aug 2020 20:12:38 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8240487 : Cleanup whitespace in .cc, .hh,
 .m, and .mm files
In-Reply-To: <5F2B6113.5030909@oracle.com>
References: <5F2B6113.5030909@oracle.com>
Message-ID: <43459381-f941-78a0-aa44-5484c0278ccb@oracle.com>

Hi Philip,

The MacosxDebuggerLocal.m changes look fine. It took a while to detect 
what was actually changed since the html files seem to convert tabs to 
spaces. I ended up looking in the patch file, and could see the tabs there.

thanks,

Chris

On 8/5/20 6:46 PM, Philip Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8240487
> Webrev: http://cr.openjdk.java.net/~prr/8240487/
>
> In advance of the move to Project Skara/git it is desirable to clean 
> up whitespace in source files
> that are not currently checked by jcheck so we can add these 
> extensions to jcheck at that time.
>
> The fix is therefore to remove tabs and trailing spaces.
>
> The 3rd party harfbuzz library has .cc and .hh files but there are no 
> current violations there
> since I've cleaned those up when importing harfbuzz upgrades.
>
> There is one JDK file that relates to those that inherited tabs that 
> is fixed.
>
> But almost all the fixes are in Objective C .m and .mm files.
> JDK has no examples of .mm but JavaFX does so I was looking just to be 
> sure.
>
> And all but one of the .m violations are in the desktop module which 
> is mainly because
> that is where all but 5 of the Objective-C files are.
>
> The only non-desktop violator is
> ./jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m
> and that is included in this webrev and why I've included 
> serviceability-dev.
>
> -phil.


From alexander.zuev at oracle.com  Thu Aug  6 05:44:59 2020
From: alexander.zuev at oracle.com (Alexander Zuev)
Date: Wed, 5 Aug 2020 22:44:59 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR: 8240487 : Cleanup whitespace in
 .cc, .hh, .m, and .mm files
In-Reply-To: <5F2B6113.5030909@oracle.com>
References: <5F2B6113.5030909@oracle.com>
Message-ID: <997582fe-09f1-3642-d3ce-21c33b3cc118@oracle.com>

Looks fine to me. Had to recall the vi settings that visualize spaces 
and tabs but
it was worth it. Some places looks hilarious, like this one:
http://cr.openjdk.java.net/~kizune/tmp/extra_spaces.png
I mean - someone spent a lot of time creating this invisible art.
Good it is going to be gone.

/Alex

On 8/5/2020 6:46 PM, Philip Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8240487
> Webrev: http://cr.openjdk.java.net/~prr/8240487/
>
> In advance of the move to Project Skara/git it is desirable to clean 
> up whitespace in source files
> that are not currently checked by jcheck so we can add these 
> extensions to jcheck at that time.
>
> The fix is therefore to remove tabs and trailing spaces.
>
> The 3rd party harfbuzz library has .cc and .hh files but there are no 
> current violations there
> since I've cleaned those up when importing harfbuzz upgrades.
>
> There is one JDK file that relates to those that inherited tabs that 
> is fixed.
>
> But almost all the fixes are in Objective C .m and .mm files.
> JDK has no examples of .mm but JavaFX does so I was looking just to be 
> sure.
>
> And all but one of the .m violations are in the desktop module which 
> is mainly because
> that is where all but 5 of the Objective-C files are.
>
> The only non-desktop violator is
> ./jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m
> and that is included in this webrev and why I've included 
> serviceability-dev.
>
> -phil.


From kevin.rushforth at oracle.com  Thu Aug  6 12:44:04 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 6 Aug 2020 05:44:04 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8240487 : Cleanup whitespace in .cc, .hh,
 .m, and .mm files
In-Reply-To: <5F2B6113.5030909@oracle.com>
References: <5F2B6113.5030909@oracle.com>
Message-ID: <256fa7cf-8913-4638-b32d-7cfe209e81a6@oracle.com>

Looks good to me. I verified that the only changes are whitespace 
changes, and that after applying the patch there are no more whitespace 
errors.

+1

-- Kevin


On 8/5/2020 6:46 PM, Philip Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8240487
> Webrev: http://cr.openjdk.java.net/~prr/8240487/
>
> In advance of the move to Project Skara/git it is desirable to clean 
> up whitespace in source files
> that are not currently checked by jcheck so we can add these 
> extensions to jcheck at that time.
>
> The fix is therefore to remove tabs and trailing spaces.
>
> The 3rd party harfbuzz library has .cc and .hh files but there are no 
> current violations there
> since I've cleaned those up when importing harfbuzz upgrades.
>
> There is one JDK file that relates to those that inherited tabs that 
> is fixed.
>
> But almost all the fixes are in Objective C .m and .mm files.
> JDK has no examples of .mm but JavaFX does so I was looking just to be 
> sure.
>
> And all but one of the .m violations are in the desktop module which 
> is mainly because
> that is where all but 5 of the Objective-C files are.
>
> The only non-desktop violator is
> ./jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m
> and that is included in this webrev and why I've included 
> serviceability-dev.
>
> -phil.


From Sergey.Bylokhov at oracle.com  Thu Aug  6 15:16:27 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 6 Aug 2020 08:16:27 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8240487 : Cleanup whitespace in .cc, .hh,
 .m, and .mm files
In-Reply-To: <5F2B6113.5030909@oracle.com>
References: <5F2B6113.5030909@oracle.com>
Message-ID: <b539038e-94a8-1be0-def3-ceaf237ee84a@oracle.com>

Hi, Phil.

Maybe we can enable jcheck for such files at the same time?

On 05.08.2020 18:46, Philip Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8240487
> Webrev: http://cr.openjdk.java.net/~prr/8240487/
> 
> In advance of the move to Project Skara/git it is desirable to clean up whitespace in source files
> that are not currently checked by jcheck so we can add these extensions to jcheck at that time.
> 
> The fix is therefore to remove tabs and trailing spaces.
> 
> The 3rd party harfbuzz library has .cc and .hh files but there are no current violations there
> since I've cleaned those up when importing harfbuzz upgrades.
> 
> There is one JDK file that relates to those that inherited tabs that is fixed.
> 
> But almost all the fixes are in Objective C .m and .mm files.
> JDK has no examples of .mm but JavaFX does so I was looking just to be sure.
> 
> And all but one of the .m violations are in the desktop module which is mainly because
> that is where all but 5 of the Objective-C files are.
> 
> The only non-desktop violator is
> ./jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m
> and that is included in this webrev and why I've included serviceability-dev.
> 
> -phil.


-- 
Best regards, Sergey.

From philip.race at oracle.com  Fri Aug  7 21:25:54 2020
From: philip.race at oracle.com (Philip Race)
Date: Fri, 07 Aug 2020 14:25:54 -0700
Subject: [OpenJDK 2D-Dev] EA4 build of Project Lanai (Metal rendering
 pipeline for macOS) is now posted.
Message-ID: <5F2DC6E2.10405@oracle.com>

https://jdk.java.net/lanai/ is now hosting the EA 4 build of Lanai


    Build 16-lanai+1-51 (2020/8/3)


List of notable fixed bugs since EA 3

  * 8233226: Implement XOR Mode rendering option
    <https://bugs.openjdk.java.net/browse/JDK-8233226>
  * 8247564: Lanai - SwingSet2 - Motif LF - UI controls border is
    incorrectly drawn with uiScale=1.0
    <https://bugs.openjdk.java.net/browse/JDK-8247564>
  * 8244402: Lanai - Motif L&F - Non selected Radio button is barely
    rendered on non-retina display
    <https://bugs.openjdk.java.net/browse/JDK-8244402>
  * 8248831: Lanai : SwingSet2Demo Input dialog is not proper for
    MetalLookAndFeel with default non-retina display
    <https://bugs.openjdk.java.net/browse/JDK-8248831>
  * 8240221: XOR mode rendering option does not work with Texture paint
    and Gradient Paint <https://bugs.openjdk.java.net/browse/JDK-8240221>
  * 8247556: Lanai : J2DDemo - ImageOps demo - Few options are not
    working... <https://bugs.openjdk.java.net/browse/JDK-8247556>
  * 8247831: Clamp texture height to maxTextureSize(16384)
    <https://bugs.openjdk.java.net/browse/JDK-8247831>
  * 8249174: Fix improper glyph cache initialization logic for text
    rende... <https://bugs.openjdk.java.net/browse/JDK-8249174>
  * 8243953: Optimize encoder creation/deletion logic for LCD text
    rendering <https://bugs.openjdk.java.net/browse/JDK-8243953>

-phil.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200807/b6767565/attachment.htm>

From Sergey.Bylokhov at oracle.com  Sun Aug  9 10:16:09 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sun, 9 Aug 2020 03:16:09 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8251123 doclint warnings about missing
 javadoc tags and comments
Message-ID: <5598de64-cad3-6167-a05d-8bc85a181d8e@oracle.com>

Hello.
Please review the fix for jdk/client.

Bug: https://bugs.openjdk.java.net/browse/JDK-8251123
Fix: http://cr.openjdk.java.net/~serb/8251123/webrev.01

We have a number of missing javadoc tags and comments in the desktop module.
Most of the missing comments are related to the serialized form.

The fix:
  - Adds missing comments to the non-static/non-transient fields(even private) of the "serializable" classes
  - Adds comments to the "serializable" classes even if those classes are non-public
  - Fixes references/adds missing tags to the special methods(like readObject/writeObject)

Also, I made additional changes:
  - In one class to suppress the warning I have made two constants static:
    http://cr.openjdk.java.net/~serb/8251123/webrev.01/src/java.desktop/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java.sdiff.html
  - Adds @Deprecated(forRemoval = true) to the PeerFixer class:
    http://cr.openjdk.java.net/~serb/8251123/webrev.01/src/java.desktop/share/classes/java/awt/ScrollPane.java.sdiff.html
    I think we should delete this class, so to not missing this in future I added
    this tag, or could I delete them right now?

I also would like to clarify the status of unused fields, like:
src/java.desktop/share/classes/java/awt/CheckboxMenuItem.java:433: warning: no comment
     private int checkboxMenuItemSerializedDataVersion = 1;
Could I add "@Deprecated(forRemoval = true)" to them as well, or could I delete them right now?


Note that in some cases I added the comments to the "implementation details", so I did not specify it fully.

-- 
Best regards, Sergey.

From philip.race at oracle.com  Mon Aug 10 20:47:58 2020
From: philip.race at oracle.com (Philip Race)
Date: Mon, 10 Aug 2020 13:47:58 -0700
Subject: [OpenJDK 2D-Dev] 8251367: [windows] harfbuzz.dll not found causes
 failure to load sun.font.SunFontManager
Message-ID: <5F31B27E.9040902@oracle.com>

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

When using something other than the java launcher (ie the jpackage launcher)
harfbuzz.dll is not found by windows dll loading.
So we need to load it explicitly else the Java class that loads 
fontmanager,dll
will fail to initialize.

At the same time, I'd like to fix a very minor inconsequential pair of 
typoes
that exclude from the build files by the wrong directory pathname.

-phil.

From Sergey.Bylokhov at oracle.com  Tue Aug 11 03:24:28 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 10 Aug 2020 20:24:28 -0700
Subject: [OpenJDK 2D-Dev] 8251367: [windows] harfbuzz.dll not found
 causes failure to load sun.font.SunFontManager
In-Reply-To: <5F31B27E.9040902@oracle.com>
References: <5F31B27E.9040902@oracle.com>
Message-ID: <add78b82-71bb-df52-d2e5-5e0e14ae037b@oracle.com>

Looks fine.

On 10.08.2020 13:47, Philip Race wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8251367
> webrev: http://cr.openjdk.java.net/~prr/8251367/
> 
> When using something other than the java launcher (ie the jpackage launcher)
> harfbuzz.dll is not found by windows dll loading.
> So we need to load it explicitly else the Java class that loads fontmanager,dll
> will fail to initialize.
> 
> At the same time, I'd like to fix a very minor inconsequential pair of typoes
> that exclude from the build files by the wrong directory pathname.
> 
> -phil.


-- 
Best regards, Sergey.

From magnus.ihse.bursie at oracle.com  Tue Aug 11 09:38:05 2020
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 11 Aug 2020 11:38:05 +0200
Subject: [OpenJDK 2D-Dev] 8251367: [windows] harfbuzz.dll not found
 causes failure to load sun.font.SunFontManager
In-Reply-To: <5F31B27E.9040902@oracle.com>
References: <5F31B27E.9040902@oracle.com>
Message-ID: <d6832d7b-2fd5-e6e9-32f9-e3668a62562a@oracle.com>



On 2020-08-10 22:47, Philip Race wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8251367
> webrev: http://cr.openjdk.java.net/~prr/8251367/
>
> When using something other than the java launcher (ie the jpackage 
> launcher)
> harfbuzz.dll is not found by windows dll loading.
> So we need to load it explicitly else the Java class that loads 
> fontmanager,dll
> will fail to initialize.
>
> At the same time, I'd like to fix a very minor inconsequential pair of 
> typoes
> that exclude from the build files by the wrong directory pathname.
Phil,

Is the exclude still needed, if the build worked fine without it..?

/Magnus
>
> -phil.


From philip.race at oracle.com  Tue Aug 11 14:58:39 2020
From: philip.race at oracle.com (Philip Race)
Date: Tue, 11 Aug 2020 07:58:39 -0700
Subject: [OpenJDK 2D-Dev] 8251367: [windows] harfbuzz.dll not found
 causes failure to load sun.font.SunFontManager
In-Reply-To: <d6832d7b-2fd5-e6e9-32f9-e3668a62562a@oracle.com>
References: <5F31B27E.9040902@oracle.com>
 <d6832d7b-2fd5-e6e9-32f9-e3668a62562a@oracle.com>
Message-ID: <5F32B21F.1090005@oracle.com>

One isn't strictly required, but the code in the file isn't used.

The other (hb-coretext.cc) needs to be excluded on other platforms 
besides macOS.

I think the build must actually strip the directory part and just look for
the filename part, else the build should have failed with the wrong path.

-phil.

On 8/11/20, 2:38 AM, Magnus Ihse Bursie wrote:
>
>
> On 2020-08-10 22:47, Philip Race wrote:
>> bug: https://bugs.openjdk.java.net/browse/JDK-8251367
>> webrev: http://cr.openjdk.java.net/~prr/8251367/
>>
>> When using something other than the java launcher (ie the jpackage 
>> launcher)
>> harfbuzz.dll is not found by windows dll loading.
>> So we need to load it explicitly else the Java class that loads 
>> fontmanager,dll
>> will fail to initialize.
>>
>> At the same time, I'd like to fix a very minor inconsequential pair 
>> of typoes
>> that exclude from the build files by the wrong directory pathname.
> Phil,
>
> Is the exclude still needed, if the build worked fine without it..?
>
> /Magnus
>>
>> -phil.
>

From Sergey.Bylokhov at oracle.com  Wed Aug 12 04:07:08 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 11 Aug 2020 21:07:08 -0700
Subject: [OpenJDK 2D-Dev] Printing to Postscript doesn't support dieresis
In-Reply-To: <1419006818.4115.8.camel@nirvana.localdomain>
References: <1415378167.7443.1.camel@nirvana.localdomain>
 <5488D8FC.2030700@oracle.com> <1418407228.25551.8.camel@nirvana.localdomain>
 <548B2FC2.2080201@oracle.com> <1418408157.25551.10.camel@nirvana.localdomain>
 <548B3CA2.3070503@oracle.com> <1419006818.4115.8.camel@nirvana.localdomain>
Message-ID: <911ef53b-a14d-5d87-1920-ee20bf598747@oracle.com>

Hi, Mario, Phil.

I would like to clarify how the test is intended to work on windows and macOS.

This fix changed encoding used in the FcFontConfiguration from UTF_8 to ISO_8859_1.
The test also expected the text in the ISO_8859_1 encoding.

Is it expected that the postscript file will be created using ISO_8859_1 on macOS and windows as well, and
not depends from the default system locale? or the test should set the default encoding to ISO_8859_1, something like this:
http://cr.openjdk.java.net/~serb/8135174/webrev.00/test/jdk/javax/print/PrintSEUmlauts/PrintSEUmlauts.java.sdiff.html


On 19.12.2014 08:33, Mario Torre wrote:
> On Fri, 2014-12-12 at 11:06 -0800, Phil Race wrote:
>> Correct. jtreg doesn't like System.exit() but I also understand that shell
>> tests are now highly frowned upon.
>> So either
>> 1) Run using "othervm" where calling System.exit() should be fine - I
>> think !?
>> 2) Don't worry about it, assuming jtreg can clean up if needed. If it can't
>> halt the test threads then that seems to be a different problem that I'd
>> expect occurs in many tests.
> 
> Looks like jtreg knows what to do. I'm still running in othervm but it
> looks like the tests are now behaving correctly:
> 
> http://cr.openjdk.java.net/~neugens/8067364/webrev.01/
> 
> I still need a second reviewer then I can proceed.
> 
> Cheers,
> Mario
> 


-- 
Best regards, Sergey.

From kumar.z.abhishek at oracle.com  Wed Aug 12 12:30:36 2020
From: kumar.z.abhishek at oracle.com (Kumar Abhishek)
Date: Wed, 12 Aug 2020 12:30:36 +0000 (UTC)
Subject: [OpenJDK 2D-Dev] RFR : 8200281: Add missing @Override
 annotations in ImageIO plugins
In-Reply-To: <e00c5b86-7817-7826-612a-b3cc694e2857@oracle.com>
References: <a070dbc1-b6e3-4e15-977b-615aea669fbd@default>
 <5F19C3AB.80807@oracle.com> <d1ed03a5-f8c9-4ba8-8859-87d0c29ffdff@default>
 <5F1B2175.2080502@oracle.com>
 <7b1e47c0-363b-c537-a761-59c97d0d1e3f@oracle.com>
 <0a1859aa-69d3-4400-b967-ccee3b266359@default>
 <560C9F88-2B3A-4697-8014-73EA0887556A@oracle.com>
 <387bec8e-01a5-46af-98b6-adaa6bfd9b7b@default>
 <B9657A38-988B-47FE-A50F-EA1B239B9D53@oracle.com>
 <e00c5b86-7817-7826-612a-b3cc694e2857@oracle.com>
Message-ID: <ca82235a-d7ff-43cd-968c-05b7984f6840@default>

Hi Alexey,

Thank you for looking into it.

I have updated the code with  below suggestion.
Please find the updated Webrev:-
Webrev link : http://cr.openjdk.java.net/~jdv/8200281/webrev.04/


Thanks,
Abhishek

-----Original Message-----
From: Alexey Ivanov 
Sent: Thursday, August 6, 2020 3:20 AM
To: Kumar Abhishek <kumar.z.abhishek at oracle.com>
Cc: Dmitry Markov <dmitry.markov at oracle.com>; Philip Race <philip.race at oracle.com>; 2d-dev <2d-dev at openjdk.java.net>
Subject: Re: [OpenJDK 2D-Dev] RFR : 8200281: Add missing @Override annotations in ImageIO plugins

Hi Abhishek,

*BMPImageReader.java*

When @Override is added to anonymous classes, the annotation is not aligned to the method declaration; at time the indentation of the method declaration is unnecessarily modified:

1937???????????? @Override
1938???????????? public void imageProgress(ImageReader source, in the original file
1927???????????????? public void imageProgress(ImageReader source,

But it's not easy to see in the webrev because it ignored indent change on the lines 1927/1938.

These are misaligned and are seen clearly:
1946???????????? @Override
1958???????????? @Override
1964???????????? @Override
1977???????????? @Override
1988???????????? @Override
1998???????????? @Override

This changes the indentation of the method declaration:
1980???????????? @Override
1981???????????? public void thumbnailPassStarted(ImageReader source,


Missing @Override annotation:
2045???????????????? public Boolean run() {


Since we're doing clean-up, a couple more warning can be addressed:

1. There are several unused imports which can be removed.

2. There are two wildcard imports:
 ? 63 import java.io.*;
 ? 64 import java.nio.*;
Shall we expand them into specific imports or leave as is?

3. The class can be made static:
2019???? private class EmbeddedProgressAdapter implements IIOReadProgressListener {


*BMPImageWriter.java*

Missing @Override annotation:
1348???????????????????? public void imageProgress(ImageWriter source, 
float percentageDone) {
1354???????????????????? public void warningOccurred(ImageWriter source, 
int imageIndex, String warning) {

The class can be made static:
1384???? private class IIOWriteProgressAdapter implements 
IIOWriteProgressListener {


*GIFImageWriter.java*

There are a couple unused imports which can be removed.


*JPEGImageReader.java*

Missing @Override annotation:
 ? 91???????????????? public Void run() {
 ?953???????????????????? protected ImageTypeSpecifier produce() {
1811????? public boolean hasNext() {
1825????? public ImageTypeSpecifier next() {
1835????? public void remove() {


*JPEGImageWriter.java*

Missing @Override annotation:
179???????????????? public Void run() {


*PNGImageReader.java*

Missing @Override annotation:
76???? public InputStream nextElement() {
86???? public boolean hasMoreElements() {

This file has been updated since the time this webrev was created; thus 
the copyright update does not apply.


*WBMPImageReader.java*

This file has a wildcard import:
43 import java.io.*;
Shall we expand it as in BMPImageReader.java?


*WBMPImageWriter.java*

Missing @Override annotation:
137???? public boolean canWriteRasters() {


Regards,
Alexey

>> On 30 Jul 2020, at 07:10, Kumar Abhishek <kumar.z.abhishek at oracle.com> wrote:
>>
>> Hi Dmitry,
>>
>> I have updated the year in the copyright section for the modified file.
>> Please find the updated Webrev:-
>> http://cr.openjdk.java.net/~jdv/8200281/webrev.03/
>>
>>
>> Thanks,
>> Abhishek
>>
>> <SNIP>
>>
>> -----Original Message-----
>> From: Alexey Ivanov
>> Sent: Saturday, July 25, 2020 2:38 AM
>> To: Kumar Abhishek <kumar.z.abhishek at oracle.com>
>> Cc: Philip Race <philip.race at oracle.com>; 2d-dev
>> <2d-dev at openjdk.java.net>
>> Subject: Re: [OpenJDK 2D-Dev] RFR : 8200281: Add missing @Override
>> annotations in ImageIO plugins
>>
>> Hi Abhishek,
>>
>> <SNIP>
>>
>> So the patch is incomplete.
>> Please verify you add @Override annotation to all overridden methods in these classes.
>>
>>
>> Regards,
>> Alexey

From Sergey.Bylokhov at oracle.com  Fri Aug 14 07:29:19 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 14 Aug 2020 00:29:19 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8251558 J2DBench should support shaped and
 translucent windows
Message-ID: <2e12d408-a1f3-2d0a-bbd2-00fc517ded8a@oracle.com>

Hello.
Please review the fix for jdk/client.

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

The 3 additional options are added to the J2DBench:
  - Rendering to the shaped frame
  - Rendering to the translucent frame
  - Rendering to the shaped and translucent frame

Note that the old "global.dest.screen" option is replaced by the
"global.dest.frame.defaultframe" so old configuration files should
be updated.

I have found that on windows the difference in performance rendering between
normal and shaped window are huge(x70!!).

I have checked that the jdk1.4 still be able to run this version when compiled by the jdk7.

Additional updates:
  - Location of the frame is tweaked, so it will not be placed out of the screen
  - "suffix.equals" is replaced back to "suffix.isEmpty"(which is supported by the jdk1.4)


BTW does anybody use the NetBeans project or ant file to build J2DBench.jar? probably
we can delete them and use the makefile instead?


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Sun Aug 16 03:48:26 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 15 Aug 2020 20:48:26 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8251469 Better cleanup for
 test/jdk/javax/imageio/SetOutput.java
Message-ID: <e95ed9f0-18da-2b3a-512a-2878ec227aca@oracle.com>

Hello.
Please review the fix for jdk/client.

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

One more test which leaks the temp file, because it does not close the IOS stream.

-- 
Best regards, Sergey.

From pankaj.b.bansal at oracle.com  Sun Aug 16 05:07:41 2020
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Sun, 16 Aug 2020 10:37:41 +0530
Subject: [OpenJDK 2D-Dev] RFR: 8251469 Better cleanup for
 test/jdk/javax/imageio/SetOutput.java
In-Reply-To: <e95ed9f0-18da-2b3a-512a-2878ec227aca@oracle.com>
References: <e95ed9f0-18da-2b3a-512a-2878ec227aca@oracle.com>
Message-ID: <f80b5fc0-025b-4c99-a1db-9f45860d6240@oracle.com>

looks good to me

-Pankaj


On 16/08/20 9:18 AM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk/client.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8251469
> Fix: http://cr.openjdk.java.net/~serb/8251469/webrev.00
>
> One more test which leaks the temp file, because it does not close the 
> IOS stream.
>


From philip.race at oracle.com  Sun Aug 16 23:55:57 2020
From: philip.race at oracle.com (Philip Race)
Date: Sun, 16 Aug 2020 16:55:57 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8251469 Better cleanup for
 test/jdk/javax/imageio/SetOutput.java
In-Reply-To: <e95ed9f0-18da-2b3a-512a-2878ec227aca@oracle.com>
References: <e95ed9f0-18da-2b3a-512a-2878ec227aca@oracle.com>
Message-ID: <5F39C78D.5010500@oracle.com>

+1

-phil

On 8/15/20, 8:48 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk/client.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8251469
> Fix: http://cr.openjdk.java.net/~serb/8251469/webrev.00
>
> One more test which leaks the temp file, because it does not close the 
> IOS stream.
>

From alexey.ivanov at oracle.com  Mon Aug 17 20:55:34 2020
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Mon, 17 Aug 2020 21:55:34 +0100
Subject: [OpenJDK 2D-Dev] RFR : 8200281: Add missing @Override
 annotations in ImageIO plugins
In-Reply-To: <ca82235a-d7ff-43cd-968c-05b7984f6840@default>
References: <a070dbc1-b6e3-4e15-977b-615aea669fbd@default>
 <5F19C3AB.80807@oracle.com> <d1ed03a5-f8c9-4ba8-8859-87d0c29ffdff@default>
 <5F1B2175.2080502@oracle.com>
 <7b1e47c0-363b-c537-a761-59c97d0d1e3f@oracle.com>
 <0a1859aa-69d3-4400-b967-ccee3b266359@default>
 <560C9F88-2B3A-4697-8014-73EA0887556A@oracle.com>
 <387bec8e-01a5-46af-98b6-adaa6bfd9b7b@default>
 <B9657A38-988B-47FE-A50F-EA1B239B9D53@oracle.com>
 <e00c5b86-7817-7826-612a-b3cc694e2857@oracle.com>
 <ca82235a-d7ff-43cd-968c-05b7984f6840@default>
Message-ID: <9477d85f-a757-e868-2ee0-5fbd692eac81@oracle.com>

Hi Abhishek,

We're getting closer but some annotations from those I listed in my 
previous email are still missing:

*BMPImageReader.java*

2067???????????????? public Boolean run() {


*JPEGImageReader.java*

954???????????????????? protected ImageTypeSpecifier produce() {


*TIFFImageWriter.java*

I also found one more missing @Override:
3687???? public Raster getTile(int tileX, int tileY) {


*WBMPImageReader.java*

Shall we also sort the imports? I mean move:
 ? 43 import java.io.IOException;
 ? 44 import java.util.ArrayList;
 ? 45 import java.util.Iterator;
to be after
 ? 33 import java.awt.image.WritableRaster;

Though It's fine with me as is.


Regards,
Alexey

On 12/08/2020 13:30, Kumar Abhishek wrote:
> Hi Alexey,
>
> Thank you for looking into it.
>
> I have updated the code with  below suggestion.
> Please find the updated Webrev:-
> Webrev link : http://cr.openjdk.java.net/~jdv/8200281/webrev.04/
>
>
> Thanks,
> Abhishek
>
> -----Original Message-----
> From: Alexey Ivanov
> Sent: Thursday, August 6, 2020 3:20 AM
> To: Kumar Abhishek <kumar.z.abhishek at oracle.com>
> Cc: Dmitry Markov <dmitry.markov at oracle.com>; Philip Race <philip.race at oracle.com>; 2d-dev <2d-dev at openjdk.java.net>
> Subject: Re: [OpenJDK 2D-Dev] RFR : 8200281: Add missing @Override annotations in ImageIO plugins
>
> Hi Abhishek,
>
> *BMPImageReader.java*
>
> <SNIP>
>
> Missing @Override annotation:
> 2045???????????????? public Boolean run() {
>
>
> <SNIP>
>
> *JPEGImageReader.java*
>
> Missing @Override annotation:
>   ?953???????????????????? protected ImageTypeSpecifier produce() {
>
>
> <SNIP>
>
> Regards,
> Alexey

From alexey.ushakov at jetbrains.com  Tue Aug 18 10:14:01 2020
From: alexey.ushakov at jetbrains.com (Alexey Ushakov)
Date: Tue, 18 Aug 2020 13:14:01 +0300
Subject: [OpenJDK 2D-Dev] RFR: 8251558 J2DBench should support shaped
 and translucent windows
In-Reply-To: <2e12d408-a1f3-2d0a-bbd2-00fc517ded8a@oracle.com>
References: <2e12d408-a1f3-2d0a-bbd2-00fc517ded8a@oracle.com>
Message-ID: <CA007781-7578-4E38-B1A6-795DF78B3B96@jetbrains.com>

Hi Sergey,

The changes looks good. 

> BTW does anybody use the NetBeans project or ant file to build J2DBench.jar? probably
> we can delete them and use the makefile instead?

We don?t use Netbeans project but ant is quite useful, especially on windows.

Best Regards,
Alexey

> On 14 Aug 2020, at 10:29, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hello.
> Please review the fix for jdk/client.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8251558
> Fix: http://cr.openjdk.java.net/~serb/8251558/webrev.00
> 
> The 3 additional options are added to the J2DBench:
> - Rendering to the shaped frame
> - Rendering to the translucent frame
> - Rendering to the shaped and translucent frame
> 
> Note that the old "global.dest.screen" option is replaced by the
> "global.dest.frame.defaultframe" so old configuration files should
> be updated.
> 
> I have found that on windows the difference in performance rendering between
> normal and shaped window are huge(x70!!).
> 
> I have checked that the jdk1.4 still be able to run this version when compiled by the jdk7.
> 
> Additional updates:
> - Location of the frame is tweaked, so it will not be placed out of the screen
> - "suffix.equals" is replaced back to "suffix.isEmpty"(which is supported by the jdk1.4)
> 
> 
> BTW does anybody use the NetBeans project or ant file to build J2DBench.jar? probably
> we can delete them and use the makefile instead?
> 
> 
> -- 
> Best regards, Sergey.


From kumar.z.abhishek at oracle.com  Tue Aug 18 14:23:30 2020
From: kumar.z.abhishek at oracle.com (Kumar Abhishek)
Date: Tue, 18 Aug 2020 07:23:30 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] RFR : 8200281: Add missing @Override
 annotations in ImageIO plugins
In-Reply-To: <9477d85f-a757-e868-2ee0-5fbd692eac81@oracle.com>
References: <a070dbc1-b6e3-4e15-977b-615aea669fbd@default>
 <5F19C3AB.80807@oracle.com> <d1ed03a5-f8c9-4ba8-8859-87d0c29ffdff@default>
 <5F1B2175.2080502@oracle.com>
 <7b1e47c0-363b-c537-a761-59c97d0d1e3f@oracle.com>
 <0a1859aa-69d3-4400-b967-ccee3b266359@default>
 <560C9F88-2B3A-4697-8014-73EA0887556A@oracle.com>
 <387bec8e-01a5-46af-98b6-adaa6bfd9b7b@default>
 <B9657A38-988B-47FE-A50F-EA1B239B9D53@oracle.com>
 <e00c5b86-7817-7826-612a-b3cc694e2857@oracle.com>
 <ca82235a-d7ff-43cd-968c-05b7984f6840@default>
 <9477d85f-a757-e868-2ee0-5fbd692eac81@oracle.com>
Message-ID: <9e7e98a2-6aef-4c24-82de-3f02c7b6ed04@default>

Hi Alexey,

Please find the updated Webrev link here:- http://cr.openjdk.java.net/~arapte/Abhishek/8200281/webrev.05
I have updated the missed annotation.


Thanks,
Abhishek
-----Original Message-----
From: Alexey Ivanov 
Sent: Tuesday, August 18, 2020 2:26 AM
To: Kumar Abhishek <kumar.z.abhishek at oracle.com>
Cc: Dmitry Markov <dmitry.markov at oracle.com>; Philip Race <philip.race at oracle.com>; 2d-dev <2d-dev at openjdk.java.net>
Subject: Re: [OpenJDK 2D-Dev] RFR : 8200281: Add missing @Override annotations in ImageIO plugins

Hi Abhishek,

We're getting closer but some annotations from those I listed in my previous email are still missing:

*BMPImageReader.java*

2067???????????????? public Boolean run() {


*JPEGImageReader.java*

954???????????????????? protected ImageTypeSpecifier produce() {


*TIFFImageWriter.java*

I also found one more missing @Override:
3687???? public Raster getTile(int tileX, int tileY) {


*WBMPImageReader.java*

Shall we also sort the imports? I mean move:
 ? 43 import java.io.IOException;
 ? 44 import java.util.ArrayList;
 ? 45 import java.util.Iterator;
to be after
 ? 33 import java.awt.image.WritableRaster;

Though It's fine with me as is.


Regards,
Alexey

On 12/08/2020 13:30, Kumar Abhishek wrote:
> Hi Alexey,
>
> Thank you for looking into it.
>
> I have updated the code with  below suggestion.
> Please find the updated Webrev:-
> Webrev link : http://cr.openjdk.java.net/~jdv/8200281/webrev.04/
>
>
> Thanks,
> Abhishek
>
> -----Original Message-----
> From: Alexey Ivanov
> Sent: Thursday, August 6, 2020 3:20 AM
> To: Kumar Abhishek <kumar.z.abhishek at oracle.com>
> Cc: Dmitry Markov <dmitry.markov at oracle.com>; Philip Race 
> <philip.race at oracle.com>; 2d-dev <2d-dev at openjdk.java.net>
> Subject: Re: [OpenJDK 2D-Dev] RFR : 8200281: Add missing @Override 
> annotations in ImageIO plugins
>
> Hi Abhishek,
>
> *BMPImageReader.java*
>
> <SNIP>
>
> Missing @Override annotation:
> 2045???????????????? public Boolean run() {
>
>
> <SNIP>
>
> *JPEGImageReader.java*
>
> Missing @Override annotation:
>   ?953???????????????????? protected ImageTypeSpecifier produce() {
>
>
> <SNIP>
>
> Regards,
> Alexey

From alexey.ivanov at oracle.com  Wed Aug 19 22:03:15 2020
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Wed, 19 Aug 2020 23:03:15 +0100
Subject: [OpenJDK 2D-Dev] RFR : 8200281: Add missing @Override
 annotations in ImageIO plugins
In-Reply-To: <9e7e98a2-6aef-4c24-82de-3f02c7b6ed04@default>
References: <a070dbc1-b6e3-4e15-977b-615aea669fbd@default>
 <5F19C3AB.80807@oracle.com> <d1ed03a5-f8c9-4ba8-8859-87d0c29ffdff@default>
 <5F1B2175.2080502@oracle.com>
 <7b1e47c0-363b-c537-a761-59c97d0d1e3f@oracle.com>
 <0a1859aa-69d3-4400-b967-ccee3b266359@default>
 <560C9F88-2B3A-4697-8014-73EA0887556A@oracle.com>
 <387bec8e-01a5-46af-98b6-adaa6bfd9b7b@default>
 <B9657A38-988B-47FE-A50F-EA1B239B9D53@oracle.com>
 <e00c5b86-7817-7826-612a-b3cc694e2857@oracle.com>
 <ca82235a-d7ff-43cd-968c-05b7984f6840@default>
 <9477d85f-a757-e868-2ee0-5fbd692eac81@oracle.com>
 <9e7e98a2-6aef-4c24-82de-3f02c7b6ed04@default>
Message-ID: <997169b9-31bd-514c-44ec-189b1b3196e4@oracle.com>

Looks good.

Regards,
Alexey

On 18/08/2020 15:23, Kumar Abhishek wrote:
> Hi Alexey,
>
> Please find the updated Webrev link here:- http://cr.openjdk.java.net/~arapte/Abhishek/8200281/webrev.05
> I have updated the missed annotation.
>
>
> Thanks,
> Abhishek
> -----Original Message-----
> From: Alexey Ivanov
> Sent: Tuesday, August 18, 2020 2:26 AM
> To: Kumar Abhishek <kumar.z.abhishek at oracle.com>
> Cc: Dmitry Markov <dmitry.markov at oracle.com>; Philip Race <philip.race at oracle.com>; 2d-dev <2d-dev at openjdk.java.net>
> Subject: Re: [OpenJDK 2D-Dev] RFR : 8200281: Add missing @Override annotations in ImageIO plugins
>
> Hi Abhishek,
>
> We're getting closer but some annotations from those I listed in my previous email are still missing:
>
> *BMPImageReader.java*
>
> 2067???????????????? public Boolean run() {
>
>
> *JPEGImageReader.java*
>
> 954???????????????????? protected ImageTypeSpecifier produce() {
>
>
> *TIFFImageWriter.java*
>
> I also found one more missing @Override:
> 3687???? public Raster getTile(int tileX, int tileY) {
>
>
> *WBMPImageReader.java*
>
> Shall we also sort the imports? I mean move:
>   ? 43 import java.io.IOException;
>   ? 44 import java.util.ArrayList;
>   ? 45 import java.util.Iterator;
> to be after
>   ? 33 import java.awt.image.WritableRaster;
>
> Though It's fine with me as is.
>
>
> Regards,
> Alexey
>
> <SNIP>

From dmitry.markov at oracle.com  Thu Aug 20 18:08:09 2020
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Thu, 20 Aug 2020 19:08:09 +0100
Subject: [OpenJDK 2D-Dev] RFR : 8200281: Add missing @Override
 annotations in ImageIO plugins
In-Reply-To: <997169b9-31bd-514c-44ec-189b1b3196e4@oracle.com>
References: <a070dbc1-b6e3-4e15-977b-615aea669fbd@default>
 <5F19C3AB.80807@oracle.com> <d1ed03a5-f8c9-4ba8-8859-87d0c29ffdff@default>
 <5F1B2175.2080502@oracle.com>
 <7b1e47c0-363b-c537-a761-59c97d0d1e3f@oracle.com>
 <0a1859aa-69d3-4400-b967-ccee3b266359@default>
 <560C9F88-2B3A-4697-8014-73EA0887556A@oracle.com>
 <387bec8e-01a5-46af-98b6-adaa6bfd9b7b@default>
 <B9657A38-988B-47FE-A50F-EA1B239B9D53@oracle.com>
 <e00c5b86-7817-7826-612a-b3cc694e2857@oracle.com>
 <ca82235a-d7ff-43cd-968c-05b7984f6840@default>
 <9477d85f-a757-e868-2ee0-5fbd692eac81@oracle.com>
 <9e7e98a2-6aef-4c24-82de-3f02c7b6ed04@default>
 <997169b9-31bd-514c-44ec-189b1b3196e4@oracle.com>
Message-ID: <F72F6D79-9200-4BF1-AE76-8F97BA6030C3@oracle.com>

+1

Regards,
Dmitry

> On 19 Aug 2020, at 23:03, Alexey Ivanov <alexey.ivanov at oracle.com> wrote:
> 
> Looks good.
> 
> Regards,
> Alexey
> 
> On 18/08/2020 15:23, Kumar Abhishek wrote:
>> Hi Alexey,
>> 
>> Please find the updated Webrev link here:- http://cr.openjdk.java.net/~arapte/Abhishek/8200281/webrev.05
>> I have updated the missed annotation.
>> 
>> 
>> Thanks,
>> Abhishek
>> -----Original Message-----
>> From: Alexey Ivanov
>> Sent: Tuesday, August 18, 2020 2:26 AM
>> To: Kumar Abhishek <kumar.z.abhishek at oracle.com>
>> Cc: Dmitry Markov <dmitry.markov at oracle.com>; Philip Race <philip.race at oracle.com>; 2d-dev <2d-dev at openjdk.java.net>
>> Subject: Re: [OpenJDK 2D-Dev] RFR : 8200281: Add missing @Override annotations in ImageIO plugins
>> 
>> Hi Abhishek,
>> 
>> We're getting closer but some annotations from those I listed in my previous email are still missing:
>> 
>> *BMPImageReader.java*
>> 
>> 2067                 public Boolean run() {
>> 
>> 
>> *JPEGImageReader.java*
>> 
>> 954                     protected ImageTypeSpecifier produce() {
>> 
>> 
>> *TIFFImageWriter.java*
>> 
>> I also found one more missing @Override:
>> 3687     public Raster getTile(int tileX, int tileY) {
>> 
>> 
>> *WBMPImageReader.java*
>> 
>> Shall we also sort the imports? I mean move:
>>    43 import java.io.IOException;
>>    44 import java.util.ArrayList;
>>    45 import java.util.Iterator;
>> to be after
>>    33 import java.awt.image.WritableRaster;
>> 
>> Though It's fine with me as is.
>> 
>> 
>> Regards,
>> Alexey
>> 
>> <SNIP>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200820/edef26c2/attachment.htm>

From Sergey.Bylokhov at oracle.com  Fri Aug 21 04:55:46 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 20 Aug 2020 21:55:46 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of
 discrete GPU
Message-ID: <12974e64-67c9-bd65-541d-c16184ff69e9@oracle.com>

Hello.
Please review the fix for jdk/client.

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

This is a review request for the bug particularly fixed some time ago:
https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html

In that review request it was found that the old fix does not work well in all cases, see:
    https://mail.openjdk.java.net/pipermail/2d-dev/2015-August/005611.html

The current fix updates an embedded plist.info, so the java will not require
discrete graphics by default, same as for any other applications.

Note that the new "metal" pipeline also does not required the discrete graphics.

The documentation for NSSupportsAutomaticGraphicsSwitching:
https://developer.apple.com/documentation/bundleresources/information_property_list/nssupportsautomaticgraphicsswitching

-- 
Best regards, Sergey.

From magnus.ihse.bursie at oracle.com  Fri Aug 21 10:02:13 2020
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 21 Aug 2020 12:02:13 +0200
Subject: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of
 discrete GPU
In-Reply-To: <12974e64-67c9-bd65-541d-c16184ff69e9@oracle.com>
References: <12974e64-67c9-bd65-541d-c16184ff69e9@oracle.com>
Message-ID: <e4dd78fa-2d5e-5d91-c57c-1ff7804fef24@oracle.com>

On 2020-08-21 06:55, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk/client.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8251854
> Fix: http://cr.openjdk.java.net/~serb/8251854/webrev.00
The fix looks good from a build perspective.

(But it highlights the fact that we have no consistent placement of 
those plist files; we should probably address that in a separate fix.)

/Magnus

>
> This is a review request for the bug particularly fixed some time ago:
> https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html
>
> In that review request it was found that the old fix does not work 
> well in all cases, see:
> https://mail.openjdk.java.net/pipermail/2d-dev/2015-August/005611.html
>
> The current fix updates an embedded plist.info, so the java will not 
> require
> discrete graphics by default, same as for any other applications.
>
> Note that the new "metal" pipeline also does not required the discrete 
> graphics.
>
> The documentation for NSSupportsAutomaticGraphicsSwitching:
> https://developer.apple.com/documentation/bundleresources/information_property_list/nssupportsautomaticgraphicsswitching 
>
>


From philip.race at oracle.com  Fri Aug 21 16:54:14 2020
From: philip.race at oracle.com (Philip Race)
Date: Fri, 21 Aug 2020 09:54:14 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8247867: Upgrade to freetype 2.10.2
Message-ID: <5F3FFC36.5000900@oracle.com>

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

Minor upgrade from 2.10.1 to 2.10.2
All the usual desktop tests pass.

the vast majority of the files are touched only with a one line 
2019->2020 copyright update
made by the freetype devs.

-phi

From Sergey.Bylokhov at oracle.com  Sat Aug 22 03:50:46 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 21 Aug 2020 20:50:46 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8247867: Upgrade to freetype 2.10.2
In-Reply-To: <5F3FFC36.5000900@oracle.com>
References: <5F3FFC36.5000900@oracle.com>
Message-ID: <947780d6-ebce-4f05-1d59-0daaea2851d6@oracle.com>

Looks fine.

On 21.08.2020 09:54, Philip Race wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8247867
> webrev: http://cr.openjdk.java.net/~prr/8247867/
> 
> Minor upgrade from 2.10.1 to 2.10.2
> All the usual desktop tests pass.
> 
> the vast majority of the files are touched only with a one line 2019->2020 copyright update
> made by the freetype devs.
> 
> -phi


-- 
Best regards, Sergey.

From philip.race at oracle.com  Mon Aug 24 19:43:31 2020
From: philip.race at oracle.com (Philip Race)
Date: Mon, 24 Aug 2020 12:43:31 -0700
Subject: [OpenJDK 2D-Dev] <Beans Dev> RFR: 8251123 doclint warnings
 about missing javadoc tags and comments
In-Reply-To: <5598de64-cad3-6167-a05d-8bc85a181d8e@oracle.com>
References: <5598de64-cad3-6167-a05d-8bc85a181d8e@oracle.com>
Message-ID: <5F441863.30502@oracle.com>



On 8/9/20, 3:16 AM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk/client.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8251123
> Fix: http://cr.openjdk.java.net/~serb/8251123/webrev.01
>
> We have a number of missing javadoc tags and comments in the desktop 
> module.
> Most of the missing comments are related to the serialized form.
>
> The fix:
>  - Adds missing comments to the non-static/non-transient fields(even 
> private) of the "serializable" classes
>  - Adds comments to the "serializable" classes even if those classes 
> are non-public
>  - Fixes references/adds missing tags to the special methods(like 
> readObject/writeObject)
>
> Also, I made additional changes:
>  - In one class to suppress the warning I have made two constants static:
>    
> http://cr.openjdk.java.net/~serb/8251123/webrev.01/src/java.desktop/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java.sdiff.html

This (above) would affect the serialised form so I am not sure about the 
change

>  - Adds @Deprecated(forRemoval = true) to the PeerFixer class:
>    
> http://cr.openjdk.java.net/~serb/8251123/webrev.01/src/java.desktop/share/classes/java/awt/ScrollPane.java.sdiff.html
>    I think we should delete this class, so to not missing this in 
> future I added
>    this tag, or could I delete them right now?

I can't see one or two releases making a difference relative to JDK 1.0
So right now would be fine but it still needs a CSR.
>
> I also would like to clarify the status of unused fields, like:
> src/java.desktop/share/classes/java/awt/CheckboxMenuItem.java:433: 
> warning: no comment
>     private int checkboxMenuItemSerializedDataVersion = 1;
> Could I add "@Deprecated(forRemoval = true)" to them as well, or could 
> I delete them right now?
>
>
Wouldn't that immediately break serialization w.r.t JDK 15 ?

-phil

> Note that in some cases I added the comments to the "implementation 
> details", so I did not specify it fully.
>

From philip.race at oracle.com  Mon Aug 24 20:35:32 2020
From: philip.race at oracle.com (Philip Race)
Date: Mon, 24 Aug 2020 13:35:32 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of
 discrete GPU
In-Reply-To: <e4dd78fa-2d5e-5d91-c57c-1ff7804fef24@oracle.com>
References: <12974e64-67c9-bd65-541d-c16184ff69e9@oracle.com>
 <e4dd78fa-2d5e-5d91-c57c-1ff7804fef24@oracle.com>
Message-ID: <5F442494.8050108@oracle.com>


Is there any performance cost to doing this ? I'd expect so. Any estimate ?

And there's then no way to explicitly request the discrete card on a 
15/16" MBP.
Should we release note this ?

-phil

On 8/21/20, 3:02 AM, Magnus Ihse Bursie wrote:
> On 2020-08-21 06:55, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for jdk/client.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8251854
>> Fix: http://cr.openjdk.java.net/~serb/8251854/webrev.00
> The fix looks good from a build perspective.
>
> (But it highlights the fact that we have no consistent placement of 
> those plist files; we should probably address that in a separate fix.)
>
> /Magnus
>
>>
>> This is a review request for the bug particularly fixed some time ago:
>> https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html
>>
>> In that review request it was found that the old fix does not work 
>> well in all cases, see:
>> https://mail.openjdk.java.net/pipermail/2d-dev/2015-August/005611.html
>>
>> The current fix updates an embedded plist.info, so the java will not 
>> require
>> discrete graphics by default, same as for any other applications.
>>
>> Note that the new "metal" pipeline also does not required the 
>> discrete graphics.
>>
>> The documentation for NSSupportsAutomaticGraphicsSwitching:
>> https://developer.apple.com/documentation/bundleresources/information_property_list/nssupportsautomaticgraphicsswitching 
>>
>>
>

From Sergey.Bylokhov at oracle.com  Tue Aug 25 06:27:25 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 24 Aug 2020 23:27:25 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of
 discrete GPU
In-Reply-To: <5F442494.8050108@oracle.com>
References: <12974e64-67c9-bd65-541d-c16184ff69e9@oracle.com>
 <e4dd78fa-2d5e-5d91-c57c-1ff7804fef24@oracle.com>
 <5F442494.8050108@oracle.com>
Message-ID: <a97a6b24-0ac1-390e-48e4-18b13f806064@oracle.com>

On 24.08.2020 13:35, Philip Race wrote:
> 
> Is there any performance cost to doing this ? I'd expect so. Any estimate ?

Yes, performance is affected for sure:

  - SwingMark:
    OGL_Base: 14000
    OGL_Fix: 24000
    Metal: 18000

  - Here is a j2dbench for the common draw operations(new/old/metal):
    http://cr.openjdk.java.net/~serb/8251854/perf/results.txt

   Summary:
   OGL_base:
     Number of tests:  24
     Overall average:  4.556306150323041E8
     Best spread:      0.16% variance
     Worst spread:     4.68% variance
     (Basis for results comparison)

   OGL_fix:
     Number of tests:  24
     Overall average:  1.0086929824044746E8
     Best spread:      0.04% variance
     Worst spread:     7.89% variance
     Comparison to basis:
       Best result:      83.41% of basis
       Worst result:     15.73% of basis
       Number of wins:   0
       Number of ties:   0
       Number of losses: 24

   metal:
     Number of tests:  24
     Overall average:  8.841681616575797E7
     Best spread:      0.08% variance
     Worst spread:     5.64% variance
     Comparison to basis:
       Best result:      248.11% of basis
       Worst result:     19.1% of basis
       Number of wins:   8
       Number of ties:   2
       Number of losses: 14
==========================================

  - Here is a j2dbench for the common draw operations(newOGL vs metal only):
    http://cr.openjdk.java.net/~serb/8251854/perf/newOGL_vs_Metal.txt
   
   Summary:
   OGL_fix:
     Number of tests:  24
     Overall average:  2.5871177969681844E7
     Best spread:      0.04% variance
     Worst spread:     7.01% variance
     (Basis for results comparison)

   metal:
     Number of tests:  24
     Overall average:  2.1896134898150157E7
     Best spread:      0.04% variance
     Worst spread:     1.98% variance
     Comparison to basis:
       Best result:      488.31% of basis
       Worst result:     30.77% of basis
       Number of wins:   14
       Number of ties:   0
       Number of losses: 10
  
> And there's then no way to explicitly request the discrete card on a 15/16" MBP.

   I have checked that the discrete card is enabled by the macOS:
   - if the full screen window is set
   - if the second monitor is connected
   Do not know any other ways to enable it.


> Should we release note this ?

Yes, I think so.
Note that it does not affect the bundled applications only apps running via java launcher.
But some(most?) bundled java applications use this flag already.


-- 
Best regards, Sergey.

From kevin.rushforth at oracle.com  Tue Aug 25 12:43:19 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 25 Aug 2020 05:43:19 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of
 discrete GPU
In-Reply-To: <a97a6b24-0ac1-390e-48e4-18b13f806064@oracle.com>
References: <12974e64-67c9-bd65-541d-c16184ff69e9@oracle.com>
 <e4dd78fa-2d5e-5d91-c57c-1ff7804fef24@oracle.com>
 <5F442494.8050108@oracle.com>
 <a97a6b24-0ac1-390e-48e4-18b13f806064@oracle.com>
Message-ID: <4f703a37-a42f-2641-f198-d77845387d41@oracle.com>

Does this only apply when the MacBook is running on battery, or will 
this affect performance even when the laptop is plugged in? If the 
latter, I wonder what Apple's rationale is for including a discrete 
graphics card that isn't used most of the time.

-- Kevin


On 8/24/2020 11:27 PM, Sergey Bylokhov wrote:
> On 24.08.2020 13:35, Philip Race wrote:
>>
>> Is there any performance cost to doing this ? I'd expect so. Any 
>> estimate ?
>
> Yes, performance is affected for sure:
>
> ?- SwingMark:
> ?? OGL_Base: 14000
> ?? OGL_Fix: 24000
> ?? Metal: 18000
>
> ?- Here is a j2dbench for the common draw operations(new/old/metal):
> ?? http://cr.openjdk.java.net/~serb/8251854/perf/results.txt
>
> ? Summary:
> ? OGL_base:
> ??? Number of tests:? 24
> ??? Overall average:? 4.556306150323041E8
> ??? Best spread:????? 0.16% variance
> ??? Worst spread:???? 4.68% variance
> ??? (Basis for results comparison)
>
> ? OGL_fix:
> ??? Number of tests:? 24
> ??? Overall average:? 1.0086929824044746E8
> ??? Best spread:????? 0.04% variance
> ??? Worst spread:???? 7.89% variance
> ??? Comparison to basis:
> ????? Best result:????? 83.41% of basis
> ????? Worst result:???? 15.73% of basis
> ????? Number of wins:?? 0
> ????? Number of ties:?? 0
> ????? Number of losses: 24
>
> ? metal:
> ??? Number of tests:? 24
> ??? Overall average:? 8.841681616575797E7
> ??? Best spread:????? 0.08% variance
> ??? Worst spread:???? 5.64% variance
> ??? Comparison to basis:
> ????? Best result:????? 248.11% of basis
> ????? Worst result:???? 19.1% of basis
> ????? Number of wins:?? 8
> ????? Number of ties:?? 2
> ????? Number of losses: 14
> ==========================================
>
> ?- Here is a j2dbench for the common draw operations(newOGL vs metal 
> only):
> http://cr.openjdk.java.net/~serb/8251854/perf/newOGL_vs_Metal.txt
> ? ? Summary:
> ? OGL_fix:
> ??? Number of tests:? 24
> ??? Overall average:? 2.5871177969681844E7
> ??? Best spread:????? 0.04% variance
> ??? Worst spread:???? 7.01% variance
> ??? (Basis for results comparison)
>
> ? metal:
> ??? Number of tests:? 24
> ??? Overall average:? 2.1896134898150157E7
> ??? Best spread:????? 0.04% variance
> ??? Worst spread:???? 1.98% variance
> ??? Comparison to basis:
> ????? Best result:????? 488.31% of basis
> ????? Worst result:???? 30.77% of basis
> ????? Number of wins:?? 14
> ????? Number of ties:?? 0
> ????? Number of losses: 10
>
>> And there's then no way to explicitly request the discrete card on a 
>> 15/16" MBP.
>
> ? I have checked that the discrete card is enabled by the macOS:
> ? - if the full screen window is set
> ? - if the second monitor is connected
> ? Do not know any other ways to enable it.
>
>
>> Should we release note this ?
>
> Yes, I think so.
> Note that it does not affect the bundled applications only apps 
> running via java launcher.
> But some(most?) bundled java applications use this flag already.
>
>


From Sergey.Bylokhov at oracle.com  Tue Aug 25 19:27:53 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 25 Aug 2020 12:27:53 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of
 discrete GPU
In-Reply-To: <4f703a37-a42f-2641-f198-d77845387d41@oracle.com>
References: <12974e64-67c9-bd65-541d-c16184ff69e9@oracle.com>
 <e4dd78fa-2d5e-5d91-c57c-1ff7804fef24@oracle.com>
 <5F442494.8050108@oracle.com>
 <a97a6b24-0ac1-390e-48e4-18b13f806064@oracle.com>
 <4f703a37-a42f-2641-f198-d77845387d41@oracle.com>
Message-ID: <1d3c5294-17a4-8dfb-0415-da9ed856e510@oracle.com>

On 25.08.2020 05:43, Kevin Rushforth wrote:
> Does this only apply when the MacBook is running on battery, or will this affect performance even when the laptop is plugged in? If the latter, I wonder what Apple's rationale is for including a discrete graphics card that isn't used most of the time.

It is applied if the "automatic graphics switching" is enabled, if the user disables
this feature for the "power adapter" mode, then the discrete graphics will be always used.

I guess by default they try to "maximize battery life":
https://support.apple.com/en-us/HT202043

> 
> -- Kevin
> 
> 
> On 8/24/2020 11:27 PM, Sergey Bylokhov wrote:
>> On 24.08.2020 13:35, Philip Race wrote:
>>>
>>> Is there any performance cost to doing this ? I'd expect so. Any estimate ?
>>
>> Yes, performance is affected for sure:
>>
>> ?- SwingMark:
>> ?? OGL_Base: 14000
>> ?? OGL_Fix: 24000
>> ?? Metal: 18000
>>
>> ?- Here is a j2dbench for the common draw operations(new/old/metal):
>> ?? http://cr.openjdk.java.net/~serb/8251854/perf/results.txt
>>
>> ? Summary:
>> ? OGL_base:
>> ??? Number of tests:? 24
>> ??? Overall average:? 4.556306150323041E8
>> ??? Best spread:????? 0.16% variance
>> ??? Worst spread:???? 4.68% variance
>> ??? (Basis for results comparison)
>>
>> ? OGL_fix:
>> ??? Number of tests:? 24
>> ??? Overall average:? 1.0086929824044746E8
>> ??? Best spread:????? 0.04% variance
>> ??? Worst spread:???? 7.89% variance
>> ??? Comparison to basis:
>> ????? Best result:????? 83.41% of basis
>> ????? Worst result:???? 15.73% of basis
>> ????? Number of wins:?? 0
>> ????? Number of ties:?? 0
>> ????? Number of losses: 24
>>
>> ? metal:
>> ??? Number of tests:? 24
>> ??? Overall average:? 8.841681616575797E7
>> ??? Best spread:????? 0.08% variance
>> ??? Worst spread:???? 5.64% variance
>> ??? Comparison to basis:
>> ????? Best result:????? 248.11% of basis
>> ????? Worst result:???? 19.1% of basis
>> ????? Number of wins:?? 8
>> ????? Number of ties:?? 2
>> ????? Number of losses: 14
>> ==========================================
>>
>> ?- Here is a j2dbench for the common draw operations(newOGL vs metal only):
>> http://cr.openjdk.java.net/~serb/8251854/perf/newOGL_vs_Metal.txt
>> ? ? Summary:
>> ? OGL_fix:
>> ??? Number of tests:? 24
>> ??? Overall average:? 2.5871177969681844E7
>> ??? Best spread:????? 0.04% variance
>> ??? Worst spread:???? 7.01% variance
>> ??? (Basis for results comparison)
>>
>> ? metal:
>> ??? Number of tests:? 24
>> ??? Overall average:? 2.1896134898150157E7
>> ??? Best spread:????? 0.04% variance
>> ??? Worst spread:???? 1.98% variance
>> ??? Comparison to basis:
>> ????? Best result:????? 488.31% of basis
>> ????? Worst result:???? 30.77% of basis
>> ????? Number of wins:?? 14
>> ????? Number of ties:?? 0
>> ????? Number of losses: 10
>>
>>> And there's then no way to explicitly request the discrete card on a 15/16" MBP.
>>
>> ? I have checked that the discrete card is enabled by the macOS:
>> ? - if the full screen window is set
>> ? - if the second monitor is connected
>> ? Do not know any other ways to enable it.
>>
>>
>>> Should we release note this ?
>>
>> Yes, I think so.
>> Note that it does not affect the bundled applications only apps running via java launcher.
>> But some(most?) bundled java applications use this flag already.
>>
>>
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Tue Aug 25 20:37:36 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 25 Aug 2020 13:37:36 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8171303
 sun/java2d/pipe/InterpolationQualityTest.java fails on Windows & Linux
Message-ID: <a7cec86f-9e7f-1c97-8b5e-d72b458fbc96@oracle.com>

Hello.
Please review the fix for jdk/client.

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

This the only test which was created to check different types of interpolation.
It checks the rendering to the VolatileImage and uses BufferedImage as a gold image.
But it does not take into account that rendering to the VolatileImage might be affected
by the HiDPI support.

-- 
Best regards, Sergey.

From philip.race at oracle.com  Tue Aug 25 21:59:50 2020
From: philip.race at oracle.com (Philip Race)
Date: Tue, 25 Aug 2020 14:59:50 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8171303
 sun/java2d/pipe/InterpolationQualityTest.java fails on Windows & Linux
In-Reply-To: <a7cec86f-9e7f-1c97-8b5e-d72b458fbc96@oracle.com>
References: <a7cec86f-9e7f-1c97-8b5e-d72b458fbc96@oracle.com>
Message-ID: <5F4589D6.6020004@oracle.com>

This is fine but
1) I like to see the bug under which you fixed it in the @bug list.
2) I am not sure I see how all the various reasons for this test failing 
can be explained by this.

-phil.

On 8/25/20, 1:37 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk/client.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8171303
> Fix: http://cr.openjdk.java.net/~serb/8171303/webrev.00
>
> This the only test which was created to check different types of 
> interpolation.
> It checks the rendering to the VolatileImage and uses BufferedImage as 
> a gold image.
> But it does not take into account that rendering to the VolatileImage 
> might be affected
> by the HiDPI support.
>

From philip.race at oracle.com  Tue Aug 25 22:40:24 2020
From: philip.race at oracle.com (Philip Race)
Date: Tue, 25 Aug 2020 15:40:24 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of
 discrete GPU
In-Reply-To: <1d3c5294-17a4-8dfb-0415-da9ed856e510@oracle.com>
References: <12974e64-67c9-bd65-541d-c16184ff69e9@oracle.com>
 <e4dd78fa-2d5e-5d91-c57c-1ff7804fef24@oracle.com>
 <5F442494.8050108@oracle.com>
 <a97a6b24-0ac1-390e-48e4-18b13f806064@oracle.com>
 <4f703a37-a42f-2641-f198-d77845387d41@oracle.com>
 <1d3c5294-17a4-8dfb-0415-da9ed856e510@oracle.com>
Message-ID: <5F459358.7070802@oracle.com>



On 8/25/20, 12:27 PM, Sergey Bylokhov wrote:
> On 25.08.2020 05:43, Kevin Rushforth wrote:
>> Does this only apply when the MacBook is running on battery, or will 
>> this affect performance even when the laptop is plugged in? If the 
>> latter, I wonder what Apple's rationale is for including a discrete 
>> graphics card that isn't used most of the time.

Based on the numbers, I wonder if we should make this change ?
>
> It is applied if the "automatic graphics switching" is enabled, if the 
> user disables
> this feature for the "power adapter" mode, then the discrete graphics 
> will be always used.

That's a bit misleading
If I disable automatic graphics switching it is disabled for BOTH batter 
and power
and vice versa. In other words there is no way to express that battery 
power should fall back
to integrated and that you only want discrete when running on the adapter.

-phil



>
> I guess by default they try to "maximize battery life":
> https://support.apple.com/en-us/HT202043
>
>>
>> -- Kevin
>>
>>
>> On 8/24/2020 11:27 PM, Sergey Bylokhov wrote:
>>> On 24.08.2020 13:35, Philip Race wrote:
>>>>
>>>> Is there any performance cost to doing this ? I'd expect so. Any 
>>>> estimate ?
>>>
>>> Yes, performance is affected for sure:
>>>
>>>  - SwingMark:
>>>    OGL_Base: 14000
>>>    OGL_Fix: 24000
>>>    Metal: 18000
>>>
>>>  - Here is a j2dbench for the common draw operations(new/old/metal):
>>>    http://cr.openjdk.java.net/~serb/8251854/perf/results.txt
>>>
>>>   Summary:
>>>   OGL_base:
>>>     Number of tests:  24
>>>     Overall average:  4.556306150323041E8
>>>     Best spread:      0.16% variance
>>>     Worst spread:     4.68% variance
>>>     (Basis for results comparison)
>>>
>>>   OGL_fix:
>>>     Number of tests:  24
>>>     Overall average:  1.0086929824044746E8
>>>     Best spread:      0.04% variance
>>>     Worst spread:     7.89% variance
>>>     Comparison to basis:
>>>       Best result:      83.41% of basis
>>>       Worst result:     15.73% of basis
>>>       Number of wins:   0
>>>       Number of ties:   0
>>>       Number of losses: 24
>>>
>>>   metal:
>>>     Number of tests:  24
>>>     Overall average:  8.841681616575797E7
>>>     Best spread:      0.08% variance
>>>     Worst spread:     5.64% variance
>>>     Comparison to basis:
>>>       Best result:      248.11% of basis
>>>       Worst result:     19.1% of basis
>>>       Number of wins:   8
>>>       Number of ties:   2
>>>       Number of losses: 14
>>> ==========================================
>>>
>>>  - Here is a j2dbench for the common draw operations(newOGL vs metal 
>>> only):
>>> http://cr.openjdk.java.net/~serb/8251854/perf/newOGL_vs_Metal.txt
>>>     Summary:
>>>   OGL_fix:
>>>     Number of tests:  24
>>>     Overall average:  2.5871177969681844E7
>>>     Best spread:      0.04% variance
>>>     Worst spread:     7.01% variance
>>>     (Basis for results comparison)
>>>
>>>   metal:
>>>     Number of tests:  24
>>>     Overall average:  2.1896134898150157E7
>>>     Best spread:      0.04% variance
>>>     Worst spread:     1.98% variance
>>>     Comparison to basis:
>>>       Best result:      488.31% of basis
>>>       Worst result:     30.77% of basis
>>>       Number of wins:   14
>>>       Number of ties:   0
>>>       Number of losses: 10
>>>
>>>> And there's then no way to explicitly request the discrete card on 
>>>> a 15/16" MBP.
>>>
>>>   I have checked that the discrete card is enabled by the macOS:
>>>   - if the full screen window is set
>>>   - if the second monitor is connected
>>>   Do not know any other ways to enable it.
>>>
>>>
>>>> Should we release note this ?
>>>
>>> Yes, I think so.
>>> Note that it does not affect the bundled applications only apps 
>>> running via java launcher.
>>> But some(most?) bundled java applications use this flag already.
>>>
>>>
>>
>
>

From Sergey.Bylokhov at oracle.com  Tue Aug 25 23:01:35 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 25 Aug 2020 16:01:35 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of
 discrete GPU
In-Reply-To: <5F459358.7070802@oracle.com>
References: <12974e64-67c9-bd65-541d-c16184ff69e9@oracle.com>
 <e4dd78fa-2d5e-5d91-c57c-1ff7804fef24@oracle.com>
 <5F442494.8050108@oracle.com>
 <a97a6b24-0ac1-390e-48e4-18b13f806064@oracle.com>
 <4f703a37-a42f-2641-f198-d77845387d41@oracle.com>
 <1d3c5294-17a4-8dfb-0415-da9ed856e510@oracle.com>
 <5F459358.7070802@oracle.com>
Message-ID: <63db8215-bf9d-69fb-c179-a0dac150b422@oracle.com>

On 25.08.2020 15:40, Philip Race wrote:
> On 8/25/20, 12:27 PM, Sergey Bylokhov wrote:
>> On 25.08.2020 05:43, Kevin Rushforth wrote:
>>> Does this only apply when the MacBook is running on battery, or will this affect performance even when the laptop is plugged in? If the latter, I wonder what Apple's rationale is for including a discrete graphics card that isn't used most of the time.
> 
> Based on the numbers, I wonder if we should make this change ?

This is how other applications work, some numbers are now aligned to the metal pipeline.
Also results are similar to other macbooks without discrete graphics.

>> It is applied if the "automatic graphics switching" is enabled, if the user disables
>> this feature for the "power adapter" mode, then the discrete graphics will be always used.
> 
> That's a bit misleading
> If I disable automatic graphics switching it is disabled for BOTH batter and power
> and vice versa. In other words there is no way to express that battery power should fall back
> to integrated and that you only want discrete when running on the adapter.

It is possible to do it manually, in the "power adapter" mode the user can disable
"automatic graphics switching", and enable it in the "battery" mode.

BTW I have never did it myself.

-- 
Best regards, Sergey.

From kevin.rushforth at oracle.com  Tue Aug 25 23:08:41 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 25 Aug 2020 16:08:41 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of
 discrete GPU
In-Reply-To: <63db8215-bf9d-69fb-c179-a0dac150b422@oracle.com>
References: <12974e64-67c9-bd65-541d-c16184ff69e9@oracle.com>
 <e4dd78fa-2d5e-5d91-c57c-1ff7804fef24@oracle.com>
 <5F442494.8050108@oracle.com>
 <a97a6b24-0ac1-390e-48e4-18b13f806064@oracle.com>
 <4f703a37-a42f-2641-f198-d77845387d41@oracle.com>
 <1d3c5294-17a4-8dfb-0415-da9ed856e510@oracle.com>
 <5F459358.7070802@oracle.com>
 <63db8215-bf9d-69fb-c179-a0dac150b422@oracle.com>
Message-ID: <65cc1055-2695-c71d-f6ce-1d4d790173ad@oracle.com>


> This is how other applications work...
> ?Also results are similar to other macbooks without discrete graphics.

That's sort of what I was getting at with my earlier question: why have 
a discrete graphics card that never / seldom gets used? This may be more 
of a question for Apple, but it seems quite strange to me.

If it switched automatically based on whether or not you were on 
battery, or some user setting that favored lower power usages over 
increased performance, then it would make sense. As it is, I'm having a 
hard time understanding the motivation.

I haven't tested an FX app yet, but since this changes the plist 
properties, I want to see whether or not FX apps are impacted.

-- Kevin


On 8/25/2020 4:01 PM, Sergey Bylokhov wrote:
> On 25.08.2020 15:40, Philip Race wrote:
>> On 8/25/20, 12:27 PM, Sergey Bylokhov wrote:
>>> On 25.08.2020 05:43, Kevin Rushforth wrote:
>>>> Does this only apply when the MacBook is running on battery, or 
>>>> will this affect performance even when the laptop is plugged in? If 
>>>> the latter, I wonder what Apple's rationale is for including a 
>>>> discrete graphics card that isn't used most of the time.
>>
>> Based on the numbers, I wonder if we should make this change ?
>
> This is how other applications work, some numbers are now aligned to 
> the metal pipeline.
> Also results are similar to other macbooks without discrete graphics.
>
>>> It is applied if the "automatic graphics switching" is enabled, if 
>>> the user disables
>>> this feature for the "power adapter" mode, then the discrete 
>>> graphics will be always used.
>>
>> That's a bit misleading
>> If I disable automatic graphics switching it is disabled for BOTH 
>> batter and power
>> and vice versa. In other words there is no way to express that 
>> battery power should fall back
>> to integrated and that you only want discrete when running on the 
>> adapter.
>
> It is possible to do it manually, in the "power adapter" mode the user 
> can disable
> "automatic graphics switching", and enable it in the "battery" mode.
>
> BTW I have never did it myself.
>


From Sergey.Bylokhov at oracle.com  Tue Aug 25 23:17:55 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 25 Aug 2020 16:17:55 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of
 discrete GPU
In-Reply-To: <65cc1055-2695-c71d-f6ce-1d4d790173ad@oracle.com>
References: <12974e64-67c9-bd65-541d-c16184ff69e9@oracle.com>
 <e4dd78fa-2d5e-5d91-c57c-1ff7804fef24@oracle.com>
 <5F442494.8050108@oracle.com>
 <a97a6b24-0ac1-390e-48e4-18b13f806064@oracle.com>
 <4f703a37-a42f-2641-f198-d77845387d41@oracle.com>
 <1d3c5294-17a4-8dfb-0415-da9ed856e510@oracle.com>
 <5F459358.7070802@oracle.com>
 <63db8215-bf9d-69fb-c179-a0dac150b422@oracle.com>
 <65cc1055-2695-c71d-f6ce-1d4d790173ad@oracle.com>
Message-ID: <37a7c0b2-adf5-edee-aab7-3e4312b19175@oracle.com>

On 25.08.2020 16:08, Kevin Rushforth wrote:
> I haven't tested an FX app yet, but since this changes the plist properties, I want to see whether or not FX apps are impacted.

It should be affected because the first variation of the fix was pushed to the FX(if nothing changed since then):
https://bugs.openjdk.java.net/browse/JDK-8132775

Since FX does not have the launcher it depends on the "bin/java" or the packed application.

> 
> -- Kevin
> 
> 
> On 8/25/2020 4:01 PM, Sergey Bylokhov wrote:
>> On 25.08.2020 15:40, Philip Race wrote:
>>> On 8/25/20, 12:27 PM, Sergey Bylokhov wrote:
>>>> On 25.08.2020 05:43, Kevin Rushforth wrote:
>>>>> Does this only apply when the MacBook is running on battery, or will this affect performance even when the laptop is plugged in? If the latter, I wonder what Apple's rationale is for including a discrete graphics card that isn't used most of the time.
>>>
>>> Based on the numbers, I wonder if we should make this change ?
>>
>> This is how other applications work, some numbers are now aligned to the metal pipeline.
>> Also results are similar to other macbooks without discrete graphics.
>>
>>>> It is applied if the "automatic graphics switching" is enabled, if the user disables
>>>> this feature for the "power adapter" mode, then the discrete graphics will be always used.
>>>
>>> That's a bit misleading
>>> If I disable automatic graphics switching it is disabled for BOTH batter and power
>>> and vice versa. In other words there is no way to express that battery power should fall back
>>> to integrated and that you only want discrete when running on the adapter.
>>
>> It is possible to do it manually, in the "power adapter" mode the user can disable
>> "automatic graphics switching", and enable it in the "battery" mode.
>>
>> BTW I have never did it myself.
>>
> 


-- 
Best regards, Sergey.

From kevin.rushforth at oracle.com  Tue Aug 25 23:22:08 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 25 Aug 2020 16:22:08 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of
 discrete GPU
In-Reply-To: <37a7c0b2-adf5-edee-aab7-3e4312b19175@oracle.com>
References: <12974e64-67c9-bd65-541d-c16184ff69e9@oracle.com>
 <e4dd78fa-2d5e-5d91-c57c-1ff7804fef24@oracle.com>
 <5F442494.8050108@oracle.com>
 <a97a6b24-0ac1-390e-48e4-18b13f806064@oracle.com>
 <4f703a37-a42f-2641-f198-d77845387d41@oracle.com>
 <1d3c5294-17a4-8dfb-0415-da9ed856e510@oracle.com>
 <5F459358.7070802@oracle.com>
 <63db8215-bf9d-69fb-c179-a0dac150b422@oracle.com>
 <65cc1055-2695-c71d-f6ce-1d4d790173ad@oracle.com>
 <37a7c0b2-adf5-edee-aab7-3e4312b19175@oracle.com>
Message-ID: <fc13125f-7764-3181-f404-f81d2c9b340f@oracle.com>



On 8/25/2020 4:17 PM, Sergey Bylokhov wrote:
> On 25.08.2020 16:08, Kevin Rushforth wrote:
>> I haven't tested an FX app yet, but since this changes the plist 
>> properties, I want to see whether or not FX apps are impacted.
>
> It should be affected because the first variation of the fix was 
> pushed to the FX(if nothing changed since then):
> https://bugs.openjdk.java.net/browse/JDK-8132775
>
> Since FX does not have the launcher it depends on the "bin/java" or 
> the packed application.

Yes, this is what I remember as well back when we were testing the bug. 
My recollection is that we only wanted to avoid using the discrete CPU 
when running on battery, although it's been a while since we first 
looked at this.

-- Kevin



>
>>
>> -- Kevin
>>
>>
>> On 8/25/2020 4:01 PM, Sergey Bylokhov wrote:
>>> On 25.08.2020 15:40, Philip Race wrote:
>>>> On 8/25/20, 12:27 PM, Sergey Bylokhov wrote:
>>>>> On 25.08.2020 05:43, Kevin Rushforth wrote:
>>>>>> Does this only apply when the MacBook is running on battery, or 
>>>>>> will this affect performance even when the laptop is plugged in? 
>>>>>> If the latter, I wonder what Apple's rationale is for including a 
>>>>>> discrete graphics card that isn't used most of the time.
>>>>
>>>> Based on the numbers, I wonder if we should make this change ?
>>>
>>> This is how other applications work, some numbers are now aligned to 
>>> the metal pipeline.
>>> Also results are similar to other macbooks without discrete graphics.
>>>
>>>>> It is applied if the "automatic graphics switching" is enabled, if 
>>>>> the user disables
>>>>> this feature for the "power adapter" mode, then the discrete 
>>>>> graphics will be always used.
>>>>
>>>> That's a bit misleading
>>>> If I disable automatic graphics switching it is disabled for BOTH 
>>>> batter and power
>>>> and vice versa. In other words there is no way to express that 
>>>> battery power should fall back
>>>> to integrated and that you only want discrete when running on the 
>>>> adapter.
>>>
>>> It is possible to do it manually, in the "power adapter" mode the 
>>> user can disable
>>> "automatic graphics switching", and enable it in the "battery" mode.
>>>
>>> BTW I have never did it myself.
>>>
>>
>
>


From philip.race at oracle.com  Tue Aug 25 23:25:53 2020
From: philip.race at oracle.com (Philip Race)
Date: Tue, 25 Aug 2020 16:25:53 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of
 discrete GPU
In-Reply-To: <63db8215-bf9d-69fb-c179-a0dac150b422@oracle.com>
References: <12974e64-67c9-bd65-541d-c16184ff69e9@oracle.com>
 <e4dd78fa-2d5e-5d91-c57c-1ff7804fef24@oracle.com>
 <5F442494.8050108@oracle.com>
 <a97a6b24-0ac1-390e-48e4-18b13f806064@oracle.com>
 <4f703a37-a42f-2641-f198-d77845387d41@oracle.com>
 <1d3c5294-17a4-8dfb-0415-da9ed856e510@oracle.com>
 <5F459358.7070802@oracle.com>
 <63db8215-bf9d-69fb-c179-a0dac150b422@oracle.com>
Message-ID: <5F459E01.3070206@oracle.com>



On 8/25/20, 4:01 PM, Sergey Bylokhov wrote:
>
>>> It is applied if the "automatic graphics switching" is enabled, if 
>>> the user disables
>>> this feature for the "power adapter" mode, then the discrete 
>>> graphics will be always used.
>>
>> That's a bit misleading
>> If I disable automatic graphics switching it is disabled for BOTH 
>> batter and power
>> and vice versa. In other words there is no way to express that 
>> battery power should fall back
>> to integrated and that you only want discrete when running on the 
>> adapter.
>
> It is possible to do it manually, in the "power adapter" mode the user 
> can disable
> "automatic graphics switching", and enable it in the "battery" mode. 

What do you mean by "manually" ?

-phil.

From Sergey.Bylokhov at oracle.com  Tue Aug 25 23:27:22 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 25 Aug 2020 16:27:22 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of
 discrete GPU
In-Reply-To: <5F459E01.3070206@oracle.com>
References: <12974e64-67c9-bd65-541d-c16184ff69e9@oracle.com>
 <e4dd78fa-2d5e-5d91-c57c-1ff7804fef24@oracle.com>
 <5F442494.8050108@oracle.com>
 <a97a6b24-0ac1-390e-48e4-18b13f806064@oracle.com>
 <4f703a37-a42f-2641-f198-d77845387d41@oracle.com>
 <1d3c5294-17a4-8dfb-0415-da9ed856e510@oracle.com>
 <5F459358.7070802@oracle.com>
 <63db8215-bf9d-69fb-c179-a0dac150b422@oracle.com>
 <5F459E01.3070206@oracle.com>
Message-ID: <147a47a8-4127-1e50-e3c9-21214adc5914@oracle.com>

On 25.08.2020 16:25, Philip Race wrote:
> 
> 
> On 8/25/20, 4:01 PM, Sergey Bylokhov wrote:
>>
>>>> It is applied if the "automatic graphics switching" is enabled, if the user disables
>>>> this feature for the "power adapter" mode, then the discrete graphics will be always used.
>>>
>>> That's a bit misleading
>>> If I disable automatic graphics switching it is disabled for BOTH batter and power
>>> and vice versa. In other words there is no way to express that battery power should fall back
>>> to integrated and that you only want discrete when running on the adapter.
>>
>> It is possible to do it manually, in the "power adapter" mode the user can disable
>> "automatic graphics switching", and enable it in the "battery" mode. 
> 
> What do you mean by "manually" ?

Open the preferences and enable/disable the switching then needed.

-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Tue Aug 25 23:35:33 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 25 Aug 2020 16:35:33 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8171303
 sun/java2d/pipe/InterpolationQualityTest.java fails on Windows & Linux
In-Reply-To: <5F4589D6.6020004@oracle.com>
References: <a7cec86f-9e7f-1c97-8b5e-d72b458fbc96@oracle.com>
 <5F4589D6.6020004@oracle.com>
Message-ID: <e93e37a2-b17b-c755-967b-eb9ddf7097f2@oracle.com>

On 25.08.2020 14:59, Philip Race wrote:
> This is fine but
> 1) I like to see the bug under which you fixed it in the @bug list.

It is not a product bug and the test isn't reworked, so it is not necessary to have this test fix in the list of bugs

> 2) I am not sure I see how all the various reasons for this test failing can be explained by this.

In the HiDPI mode the VolatileImage internally have twice more pixels than BufferedImage, so when we draw the data to
the VolatileImage and then scale it back to the size of the BufferedImage for comparison, the test fails.

> 
> -phil.
> 
> On 8/25/20, 1:37 PM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for jdk/client.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8171303
>> Fix: http://cr.openjdk.java.net/~serb/8171303/webrev.00
>>
>> This the only test which was created to check different types of interpolation.
>> It checks the rendering to the VolatileImage and uses BufferedImage as a gold image.
>> But it does not take into account that rendering to the VolatileImage might be affected
>> by the HiDPI support.
>>


-- 
Best regards, Sergey.

From philip.race at oracle.com  Wed Aug 26 18:27:12 2020
From: philip.race at oracle.com (Philip Race)
Date: Wed, 26 Aug 2020 11:27:12 -0700
Subject: [OpenJDK 2D-Dev] RFR: 7183828 Invalid Image Variant when using
 anything other than BufferedImage
In-Reply-To: <1a4a613a-369e-b083-afef-c66363207400@oracle.com>
References: <1a4a613a-369e-b083-afef-c66363207400@oracle.com>
Message-ID: <5F46A980.8090409@oracle.com>

Can you please add an evaluation to the bug report explaining what you 
intend to do.
The submitter of that bug was clearly hoping that we'd support custom 
Image subclasses
and this fix just changes the behaviour from an IAE (or similar) to 
silently ignoring them.
I'm not sure what benefit there is there. It just means that people will 
be more puzzled
as to what is going on than before.

Also now we have more checks for specific known image types.
VolatileImage is an abstract class and I'm surprised that this is 
something this fix
considers OK for subclasses to extend. Does that really work ?

I think we should have just closed this out as WNF / not an issue.

-phil.

On 7/27/20, 10:14 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk/client.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-7183828
> Fix: http://cr.openjdk.java.net/~serb/7183828/webrev.00
>
> Our DrawImage pipe, used as low-level machinery to draw the known type 
> of images, supports only
> three types of images:
>  - ToolkitImage - implemented via ImageRepresentation.drawToBufImage()
>  - VolatileImage/BufferedImage implemented via different types of "loops"
>
> We have a type check for the ToolkitImage image only, otherwise, we 
> assume that the image is
> of type VolatileImage/BufferedImage, so if the user creates its own 
> image and passes it to
> this pipe he will get an exception.
>
> After the fix, such custom images will be ignored by the DrawImage pipe.
>

From Sergey.Bylokhov at oracle.com  Wed Aug 26 23:11:52 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 26 Aug 2020 16:11:52 -0700
Subject: [OpenJDK 2D-Dev] RFR: 7183828 Invalid Image Variant when using
 anything other than BufferedImage
In-Reply-To: <5F46A980.8090409@oracle.com>
References: <1a4a613a-369e-b083-afef-c66363207400@oracle.com>
 <5F46A980.8090409@oracle.com>
Message-ID: <f32f9d45-7515-c673-7bfc-e3a451340f94@oracle.com>

On 26.08.2020 11:27, Philip Race wrote:
> Can you please add an evaluation to the bug report explaining what you intend to do.

Will do.

> The submitter of that bug was clearly hoping that we'd support custom Image subclasses
> and this fix just changes the behaviour from an IAE (or similar) to silently ignoring them.
> I'm not sure what benefit there is there. It just means that people will be more puzzled
> as to what is going on than before.

After the fix, we will start to support them to some degree. The drawImage spec does not have
any exceptions, this method can only report is the pixels were completly pushed to the
destination or nor. After the fix we will report "false" for any unsupported types of images.
The new behavior will be similar to the ToolkitImage case, when the image is not loaded yet.

> 
> Also now we have more checks for specific known image types.
> VolatileImage is an abstract class and I'm surprised that this is something this fix
> considers OK for subclasses to extend. Does that really work ?

This is a good question I'll double-check that.

> 
> I think we should have just closed this out as WNF / not an issue.
> 
> -phil.
> 
> On 7/27/20, 10:14 PM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for jdk/client.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-7183828
>> Fix: http://cr.openjdk.java.net/~serb/7183828/webrev.00
>>
>> Our DrawImage pipe, used as low-level machinery to draw the known type of images, supports only
>> three types of images:
>> ?- ToolkitImage - implemented via ImageRepresentation.drawToBufImage()
>> ?- VolatileImage/BufferedImage implemented via different types of "loops"
>>
>> We have a type check for the ToolkitImage image only, otherwise, we assume that the image is
>> of type VolatileImage/BufferedImage, so if the user creates its own image and passes it to
>> this pipe he will get an exception.
>>
>> After the fix, such custom images will be ignored by the DrawImage pipe.
>>


-- 
Best regards, Sergey.

From vipinmv1 at in.ibm.com  Thu Aug 27 13:16:26 2020
From: vipinmv1 at in.ibm.com (Vipin Mv1)
Date: Thu, 27 Aug 2020 13:16:26 +0000
Subject: [OpenJDK 2D-Dev] RFR: 8234393 [macos] printing ignores printer tray
Message-ID: <OFEE56727A.B30B183C-ON002585D1.00487AC7-002585D1.0048EAC5@notes.na.collabserv.com>

Hi,

Please find below a patch for the following issue.

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


http://cr.openjdk.java.net/~aleonard/8234393/webrev.00

Thanks & Regards
Vipin MV                                                         			
                                                                                  


From Sergey.Bylokhov at oracle.com  Thu Aug 27 17:20:39 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 27 Aug 2020 10:20:39 -0700
Subject: [OpenJDK 2D-Dev] RFR: 7183828 Invalid Image Variant when using
 anything other than BufferedImage
In-Reply-To: <f32f9d45-7515-c673-7bfc-e3a451340f94@oracle.com>
References: <1a4a613a-369e-b083-afef-c66363207400@oracle.com>
 <5F46A980.8090409@oracle.com>
 <f32f9d45-7515-c673-7bfc-e3a451340f94@oracle.com>
Message-ID: <cc3dd246-6841-25dc-8af1-68c5ed913b11@oracle.com>

Hi, Phil.
>> Also now we have more checks for specific known image types.
>> VolatileImage is an abstract class and I'm surprised that this is something this fix
>> considers OK for subclasses to extend. Does that really work ?
> 
> This is a good question I'll double-check that.

You are right, we do not support the abstract VolatileImage class as well, and it
is not possible to fix this in a similar way as I did in the first revision,
because we get this exception for VolatileImage much early.

So I tried to fix it from the other way around. All our pipelines have a special
meaning of InvalidPipeException, if the pipeline found that it cannot complete draw
operation it throws this exception which is handled by all methods in the SunGraphics2D class.

So as a fix I suggest to change the IllegalArgumentException to the InvalidPipeException.
Also we need to add try/catch block to the drawHiDPIImage(it uses the
SurfaceManager.getManager method directly)

An updated version:
http://cr.openjdk.java.net/~serb/7183828/webrev.01

-- 
Best regards, Sergey.

From philip.race at oracle.com  Thu Aug 27 18:36:22 2020
From: philip.race at oracle.com (Philip Race)
Date: Thu, 27 Aug 2020 11:36:22 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8234393 [macos] printing ignores printer
 tray
In-Reply-To: <OFEE56727A.B30B183C-ON002585D1.00487AC7-002585D1.0048EAC5@notes.na.collabserv.com>
References: <OFEE56727A.B30B183C-ON002585D1.00487AC7-002585D1.0048EAC5@notes.na.collabserv.com>
Message-ID: <5F47FD26.8090307@oracle.com>

This looks reasonable but we need to test it first before approving it.

-phil.

On 8/27/20, 6:16 AM, Vipin Mv1 wrote:
> Hi,
>
> Please find below a patch for the following issue.
>
> https://bugs.openjdk.java.net/browse/JDK-8234393
>
>
> http://cr.openjdk.java.net/~aleonard/8234393/webrev.00
>
> Thanks&  Regards
> Vipin MV                                                         			
>
>

From philip.race at oracle.com  Thu Aug 27 19:39:30 2020
From: philip.race at oracle.com (Philip Race)
Date: Thu, 27 Aug 2020 12:39:30 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8074844 : Resolve disabled warnings for
 libfontmanager
Message-ID: <5F480BF2.2060300@oracle.com>

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

This resolves the disabled compiler warnings in what is now quite a 
small fontmanager library.

I've built windows, mac and linux in our build system and run our full 
battery of automated tests and sanity checked manual.

A quick run down of how the warnings map to the changes

       DISABLED_WARNINGS_clang := sign-compare,

       DISABLED_WARNINGS_gcc := sign-compare unused-function int-to-pointer-cast,

Sign compare in both of the above are the reason for the majority of the changes in freetypeScaler.c
and also the change in hb-jdk.h


unused-function was _free_nothing in
src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc


int-to-pointer-cast was an issue for 32 bit as raised here https://bugs.openjdk.java.net/browse/JDK-8250605
when a previous removal broke 32 bit Linux. Since we don't build or test that I was flying in the dark here
using the warnings from that bug. The changes for this are those in

src/java.desktop/share/native/libfontmanager/DrawGlyphList.c
src/java.desktop/unix/native/libfontmanager/X11FontScaler.c


       DISABLED_WARNINGS_microsoft := 4018 4146 4244 4996,

The unique windows warnings were
./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): error C2220: the following warning is treated as an error
  ./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): warning C4244: '=': conversion from 'jlong' to 'long', possible loss of data

  ./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): error C2220: the following warning is treated as an error
  ./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): warning C4146: unary minus operator applied to unsigned type, result still unsigned

./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): error C2220: the following warning is treated as an error
[ ./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): warning C4996: 'GetVersion': was declared deprecated

GetVersion isn't needed any more since we aren't likely to be running on anything older than XP !

-phil.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200827/11f94bdb/attachment.htm>

From Sergey.Bylokhov at oracle.com  Thu Aug 27 19:45:46 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 27 Aug 2020 12:45:46 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8074844 : Resolve disabled warnings for
 libfontmanager
In-Reply-To: <5F480BF2.2060300@oracle.com>
References: <5F480BF2.2060300@oracle.com>
Message-ID: <acc54b8d-8492-6fe5-2d42-5a4f00454e2a@oracle.com>

Hi, Phil.

Probably we could enable WARNINGS_AS_ERRORS_xlc as well? I guess we will need a confirmation from the SAP gurus.

On 27.08.2020 12:39, Philip Race wrote:
> Bug : https://bugs.openjdk.java.net/browse/JDK-8074844
> Webrev : http://cr.openjdk.java.net/~prr/8074844/index.html
> 
> This resolves the disabled compiler warnings in what is now quite a small fontmanager library.
> 
> I've built windows, mac and linux in our build system and run our full battery of automated tests and sanity checked manual.
> 
> A quick run down of how the warnings map to the changes
> 
>  ????? DISABLED_WARNINGS_clang := sign-compare,
> 
>  ????? DISABLED_WARNINGS_gcc := sign-compare unused-function int-to-pointer-cast,
> 
> Sign compare in both of the above are the reason for the majority of the changes in freetypeScaler.c
> and also the change in hb-jdk.h
> 
> 
> unused-function was _free_nothing in
> src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc
> 
> 
> int-to-pointer-cast was an issue for 32 bit as raised here https://bugs.openjdk.java.net/browse/JDK-8250605
> when a previous removal broke 32 bit Linux. Since we don't build or test that I was flying in the dark here
> using the warnings from that bug. The changes for this are those in
> 
> src/java.desktop/share/native/libfontmanager/DrawGlyphList.c
> src/java.desktop/unix/native/libfontmanager/X11FontScaler.c
> 
> 
>  ????? DISABLED_WARNINGS_microsoft := 4018 4146 4244 4996,
> 
> The unique windows warnings were
> ./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): error C2220: the following warning is treated as an error
>  ?./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): warning C4244: '=': conversion from 'jlong' to 'long', possible loss of data
> 
>  ?./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): error C2220: the following warning is treated as an error
>  ?./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): warning C4146: unary minus operator applied to unsigned type, result still unsigned
> 
> ./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): error C2220: the following warning is treated as an error
> [ ./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): warning C4996: 'GetVersion': was declared deprecated
> 
> GetVersion isn't needed any more since we aren't likely to be running on anything older than XP !
> 
> -phil.
> 
> 
> 
> 


-- 
Best regards, Sergey.

From philip.race at oracle.com  Thu Aug 27 19:55:13 2020
From: philip.race at oracle.com (Philip Race)
Date: Thu, 27 Aug 2020 12:55:13 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8074844 : Resolve disabled warnings for
 libfontmanager
In-Reply-To: <acc54b8d-8492-6fe5-2d42-5a4f00454e2a@oracle.com>
References: <5F480BF2.2060300@oracle.com>
 <acc54b8d-8492-6fe5-2d42-5a4f00454e2a@oracle.com>
Message-ID: <5F480FA1.5050304@oracle.com>

I left that alone on purpose. I have no way of testing it and whereas 
for the 32 bit
linux case I had an idea of what to fix, for xlc all I could find was it 
came in with
https://bugs.openjdk.java.net/browse/JDK-8154087 and I've no idea what 
the problems were.

SAP or IBM can look at it if they want as a separate fix.

-phil.

On 8/27/20, 12:45 PM, Sergey Bylokhov wrote:
> Hi, Phil.
>
> Probably we could enable WARNINGS_AS_ERRORS_xlc as well? I guess we 
> will need a confirmation from the SAP gurus.
>
> On 27.08.2020 12:39, Philip Race wrote:
>> Bug : https://bugs.openjdk.java.net/browse/JDK-8074844
>> Webrev : http://cr.openjdk.java.net/~prr/8074844/index.html
>>
>> This resolves the disabled compiler warnings in what is now quite a 
>> small fontmanager library.
>>
>> I've built windows, mac and linux in our build system and run our 
>> full battery of automated tests and sanity checked manual.
>>
>> A quick run down of how the warnings map to the changes
>>
>>        DISABLED_WARNINGS_clang := sign-compare,
>>
>>        DISABLED_WARNINGS_gcc := sign-compare unused-function 
>> int-to-pointer-cast,
>>
>> Sign compare in both of the above are the reason for the majority of 
>> the changes in freetypeScaler.c
>> and also the change in hb-jdk.h
>>
>>
>> unused-function was _free_nothing in
>> src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc
>>
>>
>> int-to-pointer-cast was an issue for 32 bit as raised here 
>> https://bugs.openjdk.java.net/browse/JDK-8250605
>> when a previous removal broke 32 bit Linux. Since we don't build or 
>> test that I was flying in the dark here
>> using the warnings from that bug. The changes for this are those in
>>
>> src/java.desktop/share/native/libfontmanager/DrawGlyphList.c
>> src/java.desktop/unix/native/libfontmanager/X11FontScaler.c
>>
>>
>>        DISABLED_WARNINGS_microsoft := 4018 4146 4244 4996,
>>
>> The unique windows warnings were
>> ./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): 
>> error C2220: the following warning is treated as an error
>>   ./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): warning 
>> C4244: '=': conversion from 'jlong' to 'long', possible loss of data
>>
>>   ./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): 
>> error C2220: the following warning is treated as an error
>>   ./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): 
>> warning C4146: unary minus operator applied to unsigned type, result 
>> still unsigned
>>
>> ./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): error 
>> C2220: the following warning is treated as an error
>> [ 
>> ./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): warning 
>> C4996: 'GetVersion': was declared deprecated
>>
>> GetVersion isn't needed any more since we aren't likely to be running 
>> on anything older than XP !
>>
>> -phil.
>>
>>
>>
>>
>
>

From erik.joelsson at oracle.com  Thu Aug 27 20:38:29 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 27 Aug 2020 13:38:29 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8074844 : Resolve disabled warnings for
 libfontmanager
In-Reply-To: <5F480BF2.2060300@oracle.com>
References: <5F480BF2.2060300@oracle.com>
Message-ID: <67b9ff5a-8132-4b3d-d5a8-bf02892f3e08@oracle.com>

Build change looks good.

/Erik

On 2020-08-27 12:39, Philip Race wrote:
> Bug : https://bugs.openjdk.java.net/browse/JDK-8074844
> Webrev : http://cr.openjdk.java.net/~prr/8074844/index.html
>
> This resolves the disabled compiler warnings in what is now quite a 
> small fontmanager library.
>
> I've built windows, mac and linux in our build system and run our full 
> battery of automated tests and sanity checked manual.
>
> A quick run down of how the warnings map to the changes
>
> ????? DISABLED_WARNINGS_clang := sign-compare,
>
> ????? DISABLED_WARNINGS_gcc := sign-compare unused-function 
> int-to-pointer-cast,
>
> Sign compare in both of the above are the reason for the majority of 
> the changes in freetypeScaler.c
> and also the change in hb-jdk.h
>
>
> unused-function was _free_nothing in
> src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc
>
>
> int-to-pointer-cast was an issue for 32 bit as raised here 
> https://bugs.openjdk.java.net/browse/JDK-8250605
> when a previous removal broke 32 bit Linux. Since we don't build or 
> test that I was flying in the dark here
> using the warnings from that bug. The changes for this are those in
>
> src/java.desktop/share/native/libfontmanager/DrawGlyphList.c
> src/java.desktop/unix/native/libfontmanager/X11FontScaler.c
>
>
> ????? DISABLED_WARNINGS_microsoft := 4018 4146 4244 4996,
>
> The unique windows warnings were
> ./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): 
> error C2220: the following warning is treated as an error
> ?./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): 
> warning C4244: '=': conversion from 'jlong' to 'long', possible loss 
> of data
>
> ?./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): 
> error C2220: the following warning is treated as an error
> ?./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): 
> warning C4146: unary minus operator applied to unsigned type, result 
> still unsigned
>
> ./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): 
> error C2220: the following warning is treated as an error
> [ 
> ./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): 
> warning C4996: 'GetVersion': was declared deprecated
>
> GetVersion isn't needed any more since we aren't likely to be running 
> on anything older than XP !
>
> -phil.
>
>
>
>

From magnus.ihse.bursie at oracle.com  Fri Aug 28 08:05:22 2020
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 28 Aug 2020 10:05:22 +0200
Subject: [OpenJDK 2D-Dev] RFR: 8074844 : Resolve disabled warnings for
 libfontmanager
In-Reply-To: <5F480BF2.2060300@oracle.com>
References: <5F480BF2.2060300@oracle.com>
Message-ID: <76911e05-8c83-4916-32a9-675d2590c125@oracle.com>


On 2020-08-27 21:39, Philip Race wrote:
> Bug : https://bugs.openjdk.java.net/browse/JDK-8074844
> Webrev : http://cr.openjdk.java.net/~prr/8074844/index.html
Looks good to me.

Thank you Phil for cleaning this up!

/Magnus

>
> This resolves the disabled compiler warnings in what is now quite a 
> small fontmanager library.
>
> I've built windows, mac and linux in our build system and run our full 
> battery of automated tests and sanity checked manual.
>
> A quick run down of how the warnings map to the changes
>
> ????? DISABLED_WARNINGS_clang := sign-compare,
>
> ????? DISABLED_WARNINGS_gcc := sign-compare unused-function 
> int-to-pointer-cast,
>
> Sign compare in both of the above are the reason for the majority of 
> the changes in freetypeScaler.c
> and also the change in hb-jdk.h
>
>
> unused-function was _free_nothing in
> src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc
>
>
> int-to-pointer-cast was an issue for 32 bit as raised here 
> https://bugs.openjdk.java.net/browse/JDK-8250605
> when a previous removal broke 32 bit Linux. Since we don't build or 
> test that I was flying in the dark here
> using the warnings from that bug. The changes for this are those in
>
> src/java.desktop/share/native/libfontmanager/DrawGlyphList.c
> src/java.desktop/unix/native/libfontmanager/X11FontScaler.c
>
>
> ????? DISABLED_WARNINGS_microsoft := 4018 4146 4244 4996,
>
> The unique windows warnings were
> ./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): 
> error C2220: the following warning is treated as an error
> ?./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): 
> warning C4244: '=': conversion from 'jlong' to 'long', possible loss 
> of data
>
> ?./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): 
> error C2220: the following warning is treated as an error
> ?./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): 
> warning C4146: unary minus operator applied to unsigned type, result 
> still unsigned
>
> ./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): 
> error C2220: the following warning is treated as an error
> [ 
> ./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): 
> warning C4996: 'GetVersion': was declared deprecated
>
> GetVersion isn't needed any more since we aren't likely to be running 
> on anything older than XP !
>
> -phil.
>
>
>
>


From conor.cleary at oracle.com  Fri Aug 28 08:28:38 2020
From: conor.cleary at oracle.com (Conor Cleary)
Date: Fri, 28 Aug 2020 09:28:38 +0100
Subject: [OpenJDK 2D-Dev] RFR[8250855]: 'Address reliance on default
 constructors in the Java 2D APIs'
Message-ID: <891419e0-22aa-f9ff-ca93-5796a55819ac@oracle.com>

Hello all,

Could someone please review my changes for JDK-8250855, 'Address 
reliance on default constructors in the Java 2D APIs'? This issue 
relates to JDK-8250639 '? Address reliance on default constructors in 
the java.desktop module'. The changes address the reliance on default 
constructors by adding in basic constructors in the following classes:

  * java.awt.Image
  * java.awt.PrintJob
  * java.awt.font.GlyphVector
  * java.awt.font.LayoutPath
  * java.awt.font.LineMetrics
  * java.awt.image.AbstractMultiResolutionImage
  * java.awt.image.BufferStrategy
  * java.awt.image.ImageFilter
  * java.awt.image.RGBImageFilter
  * java.awt.image.VolatileImage
  * javax.print.PrintServiceLookup
  * javax.print.ServiceUI
  * javax.print.ServiceUIFactory
  * javax.print.StreamPrintServiceFactory
  * javax.print.event.PrintJobAdapter

A key issue is the accompanying description for each of the added 
constructors and is probably the feedback I would value most as it has 
been a point of discussion previously. I have included a specdiff to 
easily view the changes observed in the api documentation. Currently 
drafting a CSR for these changes.

  * webrev:
    http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250855/webrevs/webrev.01/
  * specdiff:
    http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250855/webrevs/webrev.01/specdiff/overview-summary.html
  * bug: https://bugs.openjdk.java.net/browse/JDK-8250855

Best Regards,

-Conor

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200828/bc852542/attachment.htm>

From philip.race at oracle.com  Fri Aug 28 14:42:32 2020
From: philip.race at oracle.com (Philip Race)
Date: Fri, 28 Aug 2020 07:42:32 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8245400: Upgrade to LittleCMS 2.11
Message-ID: <5F4917D8.7000202@oracle.com>

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

Webrev : http://cr.openjdk.java.net/~prr/8245400/

A rotuine 3rd party library upgrade.

All platforms build  + all tests pass.

-phil.

From philip.race at oracle.com  Fri Aug 28 17:53:18 2020
From: philip.race at oracle.com (Philip Race)
Date: Fri, 28 Aug 2020 10:53:18 -0700
Subject: [OpenJDK 2D-Dev] IMPORTANT - PLEASE READ - Retiring the jdk/client
 repo next week
Message-ID: <5F49448E.3020001@oracle.com>

All,

Contingent on Project Skara (ie mercurial ->git / githib) going active 
for the JDK project on schedule
on 5th September, we intend to retire the jdk/client repo/forest as part 
of this transition.

In other words, once mercurial is shut down and we move to git there 
will ONLY be the main JDK repo
and all client pushes will go there.

We will be making some internal testing changes which we hope will help 
us spot any breakages
that pushes cause in time to prevent them making their way directly into 
a promoted build but they
can't completely replace the manual testing we have been doing, so we 
will also be
dependent on folks to be extra diligent from now on and not assume there 
is a gatekeeper
who will spot their mistakes.

But we do need some time to "flush" any last changes in client to jdk 
before mercurial shuts down.

So accordingly the ABSOLUTE LATEST DROP DEAD time for pushes to 
jdk/client should be
 >> 9am PDT Tuesday 1st Sept 2020 <<

Anything pushed after that time may be lost forever :-)

We'll also  further enforce this as of 9am PDT Wednesday 2nd Sept 2020 
by making the client repo
mercurial repo read-only. The 24 hours is to help the integrator/gate 
keeper - not for your late pushes,
For example if there's a breakage we need to back out before integrating 
we might need this.
So not even "doc" or "test" changes - nothing please !

You may reasonably ask why then Tue/Wed for this if skara is not 
transitioning until Sat 5th September ?
The answer is that in an unfortunate coincidence of timing we have a big 
lab move that begins around
9am PT Wed 2nd September, and all our testing capabilities will be 
off-line for several days.
So any test jobs submitted after sometime Tuesday won't have time
to complete, and the lab move won't be complete until after the skara 
transition.

Any outstanding reviews that don't make the cut-off will of course have 
to be resubmitted as github pull requests
and any approvals they may have accumulated will need to be re-approved. 
All of this is of course true for
folks pushing directly to the mercurial main JDK repo - it is not 
related to the client repo retirement.

-Phil





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200828/dc939cb1/attachment.htm>

From Sergey.Bylokhov at oracle.com  Sat Aug 29 00:29:45 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 28 Aug 2020 17:29:45 -0700
Subject: [OpenJDK 2D-Dev] RFR[8250855]: 'Address reliance on default
 constructors in the Java 2D APIs'
In-Reply-To: <891419e0-22aa-f9ff-ca93-5796a55819ac@oracle.com>
References: <891419e0-22aa-f9ff-ca93-5796a55819ac@oracle.com>
Message-ID: <a61c09ac-968b-23fe-972b-036df1473ba2@oracle.com>

Hi, Conor.

Please use such spec for the protected constructor: "Constructor for subclasses to call":
https://cr.openjdk.java.net/~psadhukhan/8250850/webrev.1/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalTheme.java.sdiff.html

Actually the current text is also fine to me, but looks like many people use the text above as a description.

On 28.08.2020 01:28, Conor Cleary wrote:
> Hello all,
> 
> Could someone please review my changes for JDK-8250855, 'Address reliance on default constructors in the Java 2D APIs'? This issue relates to JDK-8250639 '? Address reliance on default constructors in the java.desktop module'. The changes address the reliance on default constructors by adding in basic constructors in the following classes:
> 
>   * java.awt.Image
>   * java.awt.PrintJob
>   * java.awt.font.GlyphVector
>   * java.awt.font.LayoutPath
>   * java.awt.font.LineMetrics
>   * java.awt.image.AbstractMultiResolutionImage
>   * java.awt.image.BufferStrategy
>   * java.awt.image.ImageFilter
>   * java.awt.image.RGBImageFilter
>   * java.awt.image.VolatileImage
>   * javax.print.PrintServiceLookup
>   * javax.print.ServiceUI
>   * javax.print.ServiceUIFactory
>   * javax.print.StreamPrintServiceFactory
>   * javax.print.event.PrintJobAdapter
> 
> A key issue is the accompanying description for each of the added constructors and is probably the feedback I would value most as it has been a point of discussion previously. I have included a specdiff to easily view the changes observed in the api documentation. Currently drafting a CSR for these changes.
> 
>   * webrev: http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250855/webrevs/webrev.01/
>   * specdiff: http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250855/webrevs/webrev.01/specdiff/overview-summary.html
>   * bug: https://bugs.openjdk.java.net/browse/JDK-8250855
> 
> Best Regards,
> 
> -Conor
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Sat Aug 29 00:30:18 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 28 Aug 2020 17:30:18 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8074844 : Resolve disabled warnings for
 libfontmanager
In-Reply-To: <5F480FA1.5050304@oracle.com>
References: <5F480BF2.2060300@oracle.com>
 <acc54b8d-8492-6fe5-2d42-5a4f00454e2a@oracle.com>
 <5F480FA1.5050304@oracle.com>
Message-ID: <82d591ba-8253-3a71-4309-29e8a54610ac@oracle.com>

On 27.08.2020 12:55, Philip Race wrote:
> SAP or IBM can look at it if they want as a separate fix.

ok, +1


> 
> -phil.
> 
> On 8/27/20, 12:45 PM, Sergey Bylokhov wrote:
>> Hi, Phil.
>>
>> Probably we could enable WARNINGS_AS_ERRORS_xlc as well? I guess we will need a confirmation from the SAP gurus.
>>
>> On 27.08.2020 12:39, Philip Race wrote:
>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8074844
>>> Webrev : http://cr.openjdk.java.net/~prr/8074844/index.html
>>>
>>> This resolves the disabled compiler warnings in what is now quite a small fontmanager library.
>>>
>>> I've built windows, mac and linux in our build system and run our full battery of automated tests and sanity checked manual.
>>>
>>> A quick run down of how the warnings map to the changes
>>>
>>> ?????? DISABLED_WARNINGS_clang := sign-compare,
>>>
>>> ?????? DISABLED_WARNINGS_gcc := sign-compare unused-function int-to-pointer-cast,
>>>
>>> Sign compare in both of the above are the reason for the majority of the changes in freetypeScaler.c
>>> and also the change in hb-jdk.h
>>>
>>>
>>> unused-function was _free_nothing in
>>> src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc
>>>
>>>
>>> int-to-pointer-cast was an issue for 32 bit as raised here https://bugs.openjdk.java.net/browse/JDK-8250605
>>> when a previous removal broke 32 bit Linux. Since we don't build or test that I was flying in the dark here
>>> using the warnings from that bug. The changes for this are those in
>>>
>>> src/java.desktop/share/native/libfontmanager/DrawGlyphList.c
>>> src/java.desktop/unix/native/libfontmanager/X11FontScaler.c
>>>
>>>
>>> ?????? DISABLED_WARNINGS_microsoft := 4018 4146 4244 4996,
>>>
>>> The unique windows warnings were
>>> ./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): error C2220: the following warning is treated as an error
>>> ? ./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): warning C4244: '=': conversion from 'jlong' to 'long', possible loss of data
>>>
>>> ? ./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): error C2220: the following warning is treated as an error
>>> ? ./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): warning C4146: unary minus operator applied to unsigned type, result still unsigned
>>>
>>> ./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): error C2220: the following warning is treated as an error
>>> [ ./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): warning C4996: 'GetVersion': was declared deprecated
>>>
>>> GetVersion isn't needed any more since we aren't likely to be running on anything older than XP !
>>>
>>> -phil.
>>>
>>>
>>>
>>>
>>
>>


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Sat Aug 29 01:26:03 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 28 Aug 2020 18:26:03 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8252070 Some platform-specific BLIT
 optimizations are not effective
Message-ID: <c1d28758-f0a8-f2a7-e3de-d29c0f23f445@oracle.com>

Hello.
Please review the fix for jdk/client.

Bug: https://bugs.openjdk.java.net/browse/JDK-8252070
Fix: http://cr.openjdk.java.net/~serb/8252070/webrev.01

Some of our code assumes that the native system(XRender, D3D, OGL) makes some
effective optimizations, but in some cases, we can do better.

One of the areas for improvements is direct blitting. If the source is much
bigger than the destination we should not try to copy the non-existent area
and could cut coordinates accordingly.

The actual change is:
  951         Rectangle dst =
  952                 new Rectangle(dx, dy, w, h).intersection(dstData.getBounds());
  953         if (dst.isEmpty()) {
  972                 // return
  975         }
  979         sx += dst.x - dx;
  980         sy += dst.y - dy;


See performance data and some additional comments:
https://bugs.openjdk.java.net/browse/JDK-8252070?focusedCommentId=14365864&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14365864

-- 
Best regards, Sergey.

From philip.race at oracle.com  Sat Aug 29 18:10:43 2020
From: philip.race at oracle.com (Philip Race)
Date: Sat, 29 Aug 2020 11:10:43 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8234393 [macos] printing ignores printer
 tray
In-Reply-To: <5F47FD26.8090307@oracle.com>
References: <OFEE56727A.B30B183C-ON002585D1.00487AC7-002585D1.0048EAC5@notes.na.collabserv.com>
 <5F47FD26.8090307@oracle.com>
Message-ID: <5F4A9A23.9030002@oracle.com>

PS, there's a test case in the bug. Seems like it could be used as the 
basis for a manual regression test.

Make sure you use @requires printer  as well as adding the manual and 
headful keywords
and next you'll have to check for an installed printer with multiple trays

-phil

On 8/27/20, 11:36 AM, Philip Race wrote:
> This looks reasonable but we need to test it first before approving it.
>
> -phil.
>
> On 8/27/20, 6:16 AM, Vipin Mv1 wrote:
>> Hi,
>>
>> Please find below a patch for the following issue.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8234393
>>
>>
>> http://cr.openjdk.java.net/~aleonard/8234393/webrev.00
>>
>> Thanks&  Regards
>> Vipin MV
>>
>>

From philip.race at oracle.com  Sat Aug 29 19:01:45 2020
From: philip.race at oracle.com (Philip Race)
Date: Sat, 29 Aug 2020 12:01:45 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8252070 Some platform-specific BLIT
 optimizations are not effective
In-Reply-To: <c1d28758-f0a8-f2a7-e3de-d29c0f23f445@oracle.com>
References: <c1d28758-f0a8-f2a7-e3de-d29c0f23f445@oracle.com>
Message-ID: <5F4AA619.1080903@oracle.com>

I note that you change the signature of blitSurfaceData to private.
I think this is fine. Since it is only used in this class I imagine 
whatever reason
it was supposed it might need to be over-ridden has never arisen ..

But I still had to first go check that it isn't actually used elsewhere !

I'm not sure I get the comment about the intersection operation causing 
performance problems.
Are you referring to the cost of that intersection operation itself, or 
some downstream consequence ?

-phil

On 8/28/20, 6:26 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk/client.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8252070
> Fix: http://cr.openjdk.java.net/~serb/8252070/webrev.01
>
> Some of our code assumes that the native system(XRender, D3D, OGL) 
> makes some
> effective optimizations, but in some cases, we can do better.
>
> One of the areas for improvements is direct blitting. If the source is 
> much
> bigger than the destination we should not try to copy the non-existent 
> area
> and could cut coordinates accordingly.
>
> The actual change is:
>  951         Rectangle dst =
>  952                 new Rectangle(dx, dy, w, 
> h).intersection(dstData.getBounds());
>  953         if (dst.isEmpty()) {
>  972                 // return
>  975         }
>  979         sx += dst.x - dx;
>  980         sy += dst.y - dy;
>
>
> See performance data and some additional comments:
> https://bugs.openjdk.java.net/browse/JDK-8252070?focusedCommentId=14365864&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14365864 
>
>

From Sergey.Bylokhov at oracle.com  Sat Aug 29 21:39:46 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 29 Aug 2020 14:39:46 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8252070 Some platform-specific BLIT
 optimizations are not effective
In-Reply-To: <5F4AA619.1080903@oracle.com>
References: <c1d28758-f0a8-f2a7-e3de-d29c0f23f445@oracle.com>
 <5F4AA619.1080903@oracle.com>
Message-ID: <280a87e4-8c4e-fe49-b918-88523876a36c@oracle.com>

On 29.08.2020 12:01, Philip Race wrote
> I'm not sure I get the comment about the intersection operation causing performance problems.
> Are you referring to the cost of that intersection operation itself, or some downstream consequence ?

Yes, I am talking about the cost of intersection itself.

-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Sun Aug 30 00:29:44 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 29 Aug 2020 17:29:44 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8252133 The
 java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java fails if metal
 pipeline is active
Message-ID: <759cf878-1595-7a10-87d1-92d3f425b445@oracle.com>

Hello.
Please review the fix for jdk/client.

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

This bug easily reproduced by the test in question on the dual video card systems
when the metal pipeline is active. But it is possible to reproduce it in the OGL
pipeline as well, but it is required some additional steps.


Problem description:
   Our CGraphicsEnvironment maintains the list of active graphics devices. The one
important feature of this CGraphicsEnvironment is to invalidate the old devices and
map them to the new devices. For example, if the user got a reference to the device,
and this device was removed then this reference will refer to the main screen.

The problem in the current implementation arise when the system has two video cards:
  1 The user get some GraphicsDevice
  2 The user sets the full-screen window for this device
  3 The user change screen resolution for this device
  4 The resolution of the screen is not changed ->> BUG.

The problem is that somewhere after step 1 or 2 and before step 3 the macOS decided
to switch to the discrete video card, but it does not report the old device(integrated VC)
as removed, because actually no screens were removed.

Since it was not reported as removed we did not invalidate it and did not map it to the
new device ->> request to change the screen resolution at step 3 send to some non existed
deviceID.

As a fix I suggest to change this logic:
  - Invalidate devices reported by macOS as removed
  - Initialize the main screen
  - Initialize all NEW screens

To this logic:
  - Ignore devices reported by the macOS as removed
  - Initialize the main screen
  - Initialize all NEW screens
  - Check that the main device is in the list of all NEW devices
  - Invalidate all OLD devices which are not in the list of NEW devices


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Sun Aug 30 00:39:52 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 29 Aug 2020 17:39:52 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8245400: Upgrade to LittleCMS 2.11
In-Reply-To: <5F4917D8.7000202@oracle.com>
References: <5F4917D8.7000202@oracle.com>
Message-ID: <9e1dee80-5ea9-ee55-2f4c-d5d511e38b37@oracle.com>

Looks fine.

On 28.08.2020 07:42, Philip Race wrote:
> Bug : https://bugs.openjdk.java.net/browse/JDK-8245400
> 
> Webrev : http://cr.openjdk.java.net/~prr/8245400/
> 
> A rotuine 3rd party library upgrade.
> 
> All platforms build? + all tests pass.
> 
> -phil.


-- 
Best regards, Sergey.

From philip.race at oracle.com  Sun Aug 30 00:39:51 2020
From: philip.race at oracle.com (Phil Race)
Date: Sat, 29 Aug 2020 17:39:51 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8252133 The
 java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java fails if metal
 pipeline is active
In-Reply-To: <759cf878-1595-7a10-87d1-92d3f425b445@oracle.com>
References: <759cf878-1595-7a10-87d1-92d3f425b445@oracle.com>
Message-ID: <8BDF72CA-ACA7-4BD1-B37B-52B80ABFFD6F@oracle.com>

Sergey,

The priority now is to flush outstanding review requests ahead of the skara transition. I should have made that clearer in my email but I think new requests such as this will need to wait. Especially anything that requires some deep thought by a reviewer as we have just one working day left.

-Phil.

> On Aug 29, 2020, at 5:29 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> ?Hello.
> Please review the fix for jdk/client.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8252133
> Fix: http://cr.openjdk.java.net/~serb/8252133/webrev.00
> 
> This bug easily reproduced by the test in question on the dual video card systems
> when the metal pipeline is active. But it is possible to reproduce it in the OGL
> pipeline as well, but it is required some additional steps.
> 
> 
> Problem description:
>  Our CGraphicsEnvironment maintains the list of active graphics devices. The one
> important feature of this CGraphicsEnvironment is to invalidate the old devices and
> map them to the new devices. For example, if the user got a reference to the device,
> and this device was removed then this reference will refer to the main screen.
> 
> The problem in the current implementation arise when the system has two video cards:
> 1 The user get some GraphicsDevice
> 2 The user sets the full-screen window for this device
> 3 The user change screen resolution for this device
> 4 The resolution of the screen is not changed ->> BUG.
> 
> The problem is that somewhere after step 1 or 2 and before step 3 the macOS decided
> to switch to the discrete video card, but it does not report the old device(integrated VC)
> as removed, because actually no screens were removed.
> 
> Since it was not reported as removed we did not invalidate it and did not map it to the
> new device ->> request to change the screen resolution at step 3 send to some non existed
> deviceID.
> 
> As a fix I suggest to change this logic:
> - Invalidate devices reported by macOS as removed
> - Initialize the main screen
> - Initialize all NEW screens
> 
> To this logic:
> - Ignore devices reported by the macOS as removed
> - Initialize the main screen
> - Initialize all NEW screens
> - Check that the main device is in the list of all NEW devices
> - Invalidate all OLD devices which are not in the list of NEW devices
> 
> 
> -- 
> Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Sun Aug 30 00:45:36 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 29 Aug 2020 17:45:36 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8252133 The
 java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java fails if metal
 pipeline is active
In-Reply-To: <8BDF72CA-ACA7-4BD1-B37B-52B80ABFFD6F@oracle.com>
References: <759cf878-1595-7a10-87d1-92d3f425b445@oracle.com>
 <8BDF72CA-ACA7-4BD1-B37B-52B80ABFFD6F@oracle.com>
Message-ID: <1d397660-e7b1-c222-86dd-d79a91552a96@oracle.com>

On 29.08.2020 17:39, Phil Race wrote:
> Sergey,
> 
> The priority now is to flush outstanding review requests ahead of the skara transition. I should have made that clearer in my email but I think new requests such as this will need to wait. Especially anything that requires some deep thought by a reviewer as we have just one working day left.

It is not a big deal to convert such a request to the PR. So I will work to
the usual rhythm and convert all review requests to PR once we moved to the github.

> 
> -Phil.
> 
>> On Aug 29, 2020, at 5:29 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>>
>> ?Hello.
>> Please review the fix for jdk/client.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8252133
>> Fix: http://cr.openjdk.java.net/~serb/8252133/webrev.00
>>
>> This bug easily reproduced by the test in question on the dual video card systems
>> when the metal pipeline is active. But it is possible to reproduce it in the OGL
>> pipeline as well, but it is required some additional steps.
>>
>>
>> Problem description:
>>   Our CGraphicsEnvironment maintains the list of active graphics devices. The one
>> important feature of this CGraphicsEnvironment is to invalidate the old devices and
>> map them to the new devices. For example, if the user got a reference to the device,
>> and this device was removed then this reference will refer to the main screen.
>>
>> The problem in the current implementation arise when the system has two video cards:
>> 1 The user get some GraphicsDevice
>> 2 The user sets the full-screen window for this device
>> 3 The user change screen resolution for this device
>> 4 The resolution of the screen is not changed ->> BUG.
>>
>> The problem is that somewhere after step 1 or 2 and before step 3 the macOS decided
>> to switch to the discrete video card, but it does not report the old device(integrated VC)
>> as removed, because actually no screens were removed.
>>
>> Since it was not reported as removed we did not invalidate it and did not map it to the
>> new device ->> request to change the screen resolution at step 3 send to some non existed
>> deviceID.
>>
>> As a fix I suggest to change this logic:
>> - Invalidate devices reported by macOS as removed
>> - Initialize the main screen
>> - Initialize all NEW screens
>>
>> To this logic:
>> - Ignore devices reported by the macOS as removed
>> - Initialize the main screen
>> - Initialize all NEW screens
>> - Check that the main device is in the list of all NEW devices
>> - Invalidate all OLD devices which are not in the list of NEW devices
>>
>>
>> -- 
>> Best regards, Sergey.
> 


-- 
Best regards, Sergey.

From philip.race at oracle.com  Sun Aug 30 16:31:13 2020
From: philip.race at oracle.com (Philip Race)
Date: Sun, 30 Aug 2020 09:31:13 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8234393 [macos] printing ignores printer
 tray
In-Reply-To: <5F4A9A23.9030002@oracle.com>
References: <OFEE56727A.B30B183C-ON002585D1.00487AC7-002585D1.0048EAC5@notes.na.collabserv.com>
 <5F47FD26.8090307@oracle.com> <5F4A9A23.9030002@oracle.com>
Message-ID: <5F4BD451.9020200@oracle.com>

PS there is an existing manual regression test but it is currently 
geared towards Linux and in fact is set to run only on Linux
test/jdk/java/awt/print/PrinterJob/TestMediaTraySelection.java
So you still may find it easier to create a new test rather than modify 
this one to avoid breaking what it tests.

-phil


On 8/29/20, 11:10 AM, Philip Race wrote:
> PS, there's a test case in the bug. Seems like it could be used as the 
> basis for a manual regression test.
>
> Make sure you use @requires printer  as well as adding the manual and 
> headful keywords
> and next you'll have to check for an installed printer with multiple 
> trays
>
> -phil
>
> On 8/27/20, 11:36 AM, Philip Race wrote:
>> This looks reasonable but we need to test it first before approving it.
>>
>> -phil.
>>
>> On 8/27/20, 6:16 AM, Vipin Mv1 wrote:
>>> Hi,
>>>
>>> Please find below a patch for the following issue.
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8234393
>>>
>>>
>>> http://cr.openjdk.java.net/~aleonard/8234393/webrev.00
>>>
>>> Thanks&  Regards
>>> Vipin MV
>>>
>>>

From JAYATHIRTH.D.V at ORACLE.COM  Mon Aug 31 05:20:03 2020
From: JAYATHIRTH.D.V at ORACLE.COM (Jayathirth D v)
Date: Mon, 31 Aug 2020 10:50:03 +0530
Subject: [OpenJDK 2D-Dev] RFR: 8245400: Upgrade to LittleCMS 2.11
In-Reply-To: <9e1dee80-5ea9-ee55-2f4c-d5d511e38b37@oracle.com>
References: <5F4917D8.7000202@oracle.com>
 <9e1dee80-5ea9-ee55-2f4c-d5d511e38b37@oracle.com>
Message-ID: <F2810EDF-0D62-4E2A-A1AB-CFD1CDC11C00@ORACLE.COM>

+1.

Thanks,
Jay

> On 30-Aug-2020, at 6:09 AM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Looks fine.
> 
> On 28.08.2020 07:42, Philip Race wrote:
>> Bug : https://bugs.openjdk.java.net/browse/JDK-8245400
>> Webrev : http://cr.openjdk.java.net/~prr/8245400/
>> A rotuine 3rd party library upgrade.
>> All platforms build  + all tests pass.
>> -phil.
> 
> 
> -- 
> Best regards, Sergey.


From vipinmv1 at in.ibm.com  Mon Aug 31 12:22:29 2020
From: vipinmv1 at in.ibm.com (Vipin Mv1)
Date: Mon, 31 Aug 2020 12:22:29 +0000
Subject: [OpenJDK 2D-Dev] [EXTERNAL] Re: RFR: 8234393 [macos] printing
 ignores printer tray
In-Reply-To: <5F4BD451.9020200@oracle.com>
References: <5F4BD451.9020200@oracle.com>,
 <OFEE56727A.B30B183C-ON002585D1.00487AC7-002585D1.0048EAC5@notes.na.collabserv.com>
 <5F47FD26.8090307@oracle.com> <5F4A9A23.9030002@oracle.com>
Message-ID: <337d2fphd7-1@userp2030.oracle.com>

Hi Philip,

Thanks for the review comments. The testcase test/jdk/java/awt/print/PrinterJob/TestMediaTraySelection.java seems to be intended to test only the MediaTray functionality. Also, it doesn't seems to have anything that is Linux specific.

Rather than having a new testcase wouldn't it be fine to have os.family == "mac" change alone to the existing one.?

Regarding the testing, the patch was already tested by our customer using a multi tray printer and was found to be working. Owing to WFH factor due to COVID19, multi tray printer is not accessible to us at this point of time.

May I request if the community can help us do further testing with the multi tray printer.

Thanks & Regards
Vipin MV

-----Philip Race <philip.race at oracle.com> wrote: -----
To: Vipin Mv1 <vipinmv1 at in.ibm.com>
From: Philip Race <philip.race at oracle.com>
Date: 08/30/2020 10:02PM
Cc: 2d-dev at openjdk.java.net
Subject: [EXTERNAL] Re: [OpenJDK 2D-Dev] RFR: 8234393 [macos] printing ignores printer tray

PS there is an existing manual regression test but it is currently 
geared towards Linux and in fact is set to run only on Linux
test/jdk/java/awt/print/PrinterJob/TestMediaTraySelection.java
So you still may find it easier to create a new test rather than modify 
this one to avoid breaking what it tests.

-phil


On 8/29/20, 11:10 AM, Philip Race wrote:
> PS, there's a test case in the bug. Seems like it could be used as the 
> basis for a manual regression test.
>
> Make sure you use @requires printer  as well as adding the manual and 
> headful keywords
> and next you'll have to check for an installed printer with multiple 
> trays
>
> -phil
>
> On 8/27/20, 11:36 AM, Philip Race wrote:
>> This looks reasonable but we need to test it first before approving it.
>>
>> -phil.
>>
>> On 8/27/20, 6:16 AM, Vipin Mv1 wrote:
>>> Hi,
>>>
>>> Please find below a patch for the following issue.
>>>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8234393&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=YGcJOWSLdBGnjzzUPMOeoQB-1IAycTyy6T7cx_ZtPhM&m=SK-6ut1nk3emw0KXZM-vnvEkPaR30_91LDrjdVlgGXQ&s=79-ArdhpL1L3pemMcoI_Gcu8U-DYOGA-WHiRSN-nmeo&e= 
>>>
>>>
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Ealeonard_8234393_webrev.00&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=YGcJOWSLdBGnjzzUPMOeoQB-1IAycTyy6T7cx_ZtPhM&m=SK-6ut1nk3emw0KXZM-vnvEkPaR30_91LDrjdVlgGXQ&s=7JlYOmTp1P0BSU_rcAmw2HQA6Qhmd-VuEasiHDr1tjc&e= 
>>>
>>> Thanks&  Regards
>>> Vipin MV
>>>
>>>



From philip.race at oracle.com  Mon Aug 31 20:15:38 2020
From: philip.race at oracle.com (Philip Race)
Date: Mon, 31 Aug 2020 13:15:38 -0700
Subject: [OpenJDK 2D-Dev] RFR[8250855]: 'Address reliance on default
 constructors in the Java 2D APIs'
In-Reply-To: <a61c09ac-968b-23fe-972b-036df1473ba2@oracle.com>
References: <891419e0-22aa-f9ff-ca93-5796a55819ac@oracle.com>
 <a61c09ac-968b-23fe-972b-036df1473ba2@oracle.com>
Message-ID: <5F4D5A6A.90009@oracle.com>

Right we have started to be consistent using "Constructor for subclasses 
to call":

Also I prefer constructs over creates, even for the concrete classes, eg 
this :
+
+    /**
+     * Creates an {@code ImageFilter}.
+     */
+    public ImageFilter() {}
+

should be "Constructs an {@code ImageFilter}"

-phil.

On 8/28/20, 5:29 PM, Sergey Bylokhov wrote:
> Hi, Conor.
>
> Please use such spec for the protected constructor: "Constructor for 
> subclasses to call":
> https://cr.openjdk.java.net/~psadhukhan/8250850/webrev.1/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalTheme.java.sdiff.html 
>
>
> Actually the current text is also fine to me, but looks like many 
> people use the text above as a description.
>
> On 28.08.2020 01:28, Conor Cleary wrote:
>> Hello all,
>>
>> Could someone please review my changes for JDK-8250855, 'Address 
>> reliance on default constructors in the Java 2D APIs'? This issue 
>> relates to JDK-8250639 '? Address reliance on default constructors in 
>> the java.desktop module'. The changes address the reliance on default 
>> constructors by adding in basic constructors in the following classes:
>>
>>   * java.awt.Image
>>   * java.awt.PrintJob
>>   * java.awt.font.GlyphVector
>>   * java.awt.font.LayoutPath
>>   * java.awt.font.LineMetrics
>>   * java.awt.image.AbstractMultiResolutionImage
>>   * java.awt.image.BufferStrategy
>>   * java.awt.image.ImageFilter
>>   * java.awt.image.RGBImageFilter
>>   * java.awt.image.VolatileImage
>>   * javax.print.PrintServiceLookup
>>   * javax.print.ServiceUI
>>   * javax.print.ServiceUIFactory
>>   * javax.print.StreamPrintServiceFactory
>>   * javax.print.event.PrintJobAdapter
>>
>> A key issue is the accompanying description for each of the added 
>> constructors and is probably the feedback I would value most as it 
>> has been a point of discussion previously. I have included a specdiff 
>> to easily view the changes observed in the api documentation. 
>> Currently drafting a CSR for these changes.
>>
>>   * webrev: 
>> http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250855/webrevs/webrev.01/
>>   * specdiff: 
>> http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250855/webrevs/webrev.01/specdiff/overview-summary.html
>>   * bug: https://bugs.openjdk.java.net/browse/JDK-8250855
>>
>> Best Regards,
>>
>> -Conor
>>
>
>